This is an archive of the discontinued LLVM Phabricator instance.

Fix assertion in google-explicit-constructor check when the constructor is defined in a macro.
ClosedPublic

Authored by alexfh on May 5 2014, 9:04 AM.

Diff Detail

Event Timeline

alexfh updated this revision to Diff 9080.May 5 2014, 9:04 AM
alexfh retitled this revision from to Fix assertion in google-explicit-constructor check when the constructor is defined in a macro..
alexfh updated this object.
alexfh edited the test plan for this revision. (Show Details)
alexfh added a reviewer: klimek.
alexfh added a subscriber: Unknown Object (MLST).
klimek added inline comments.May 5 2014, 11:28 AM
clang-tidy/google/GoogleTidyModule.cpp
37

This seems a very conservative approach, as there seem to be many cases where we can provide a fix in a macro... Perhaps we can use Lexer::makeFileCharRange?

This seems a very conservative approach, as there seem to be many cases where we can provide a fix in a macro...

Do you know a way to ensure that a change to a macro is safe? We don't want to remove "explicit" from a definition of a compatibility macro, for example ;)

Also, this case is quite rare. I've found only one instance internally. So maybe we shouldn't worry much about it.

Perhaps we can use Lexer::makeFileCharRange?

This could be used to avoid problems with other (possible, but extremely rare) corner cases.

klimek accepted this revision.May 5 2014, 11:56 AM
klimek edited edge metadata.
This revision is now accepted and ready to land.May 5 2014, 11:56 AM
alexfh closed this revision.May 5 2014, 11:56 AM