If a namespace is a macro name, it should be allowed to close the
namespace with the same name.
This commit adds also unit tests for llvm-namespace-comment.
Differential D69855
[clang-tidy] Fix llvm-namespace-comment for macro expansions twardakm on Nov 5 2019, 9:34 AM. Authored by
Details
If a namespace is a macro name, it should be allowed to close the This commit adds also unit tests for llvm-namespace-comment.
Diff Detail
Event Timeline
Comment Actions There's a design question about why it should accept the expanded macro name instead of requiring the user to write the macro. I am worried about allowing the expanded form because the presumable use of a macro is to control the name, so this invites name mismatches in other configuration modes.
Comment Actions Apply Aaron's comments
Comment Actions Thanks for the review! @aaron.ballman take a look at new revision and let me know if something needs to be fixed. Thanks!
Comment Actions LGTM!
Comment Actions @aaron.ballman thanks for the review :) Can you please push the change on my behalf? I don't have commit rights. Comment Actions I've commit on your behalf in 4736d63f752f8d13f4c6a9afd558565c32119718, thank you for the patch! Comment Actions There's a problem with this patch. Consider the following code: // In some remote header: #define SOME_RANDOM_MACRO internal // In a completely unrelated file that transitively includes the header: namespace internal { void f(); } // namespace internal It makes the check think that every namespace named internal has something to do with SOME_RANDOM_MACRO. $ clang_tidy -checks=-*,llvm-* /tmp/q.cc -- 1 warning generated. /tmp/q.cc:7:2: warning: namespace 'SOME_RANDOM_MACRO' ends with a comment that refers to an expansion of macro [llvm-namespace-comment] } // namespace internal ^~~~~~~~~~~~~~~~~~~~~~ // namespace SOME_RANDOM_MACRO /tmp/q.cc:5:11: note: namespace 'SOME_RANDOM_MACRO' starts here namespace internal { ^ This is definitely wrong and it introduces tons of false positives in our code. It seems to me that the check shouldn't look any further than what is actually spelled in the namespace declaration. It shouldn't try to match macros to their expansions or vice versa. I'll see whether I can implement this quickly, otherwise I'll just revert this patch to unbreak the checker. Comment Actions @twardakm: I'm not convinced this feature is worth implementing at all, because there's a good alternative to a macro here -- a namespace alias. What is the reason to use a macro instead of a namespace alias? Comment Actions The reason for this whole patch was a bug in clang-tidy, which caused warning in the following code: #define SOME_RANDOM_MACRO macro namespace SOME_RANDOM_MACRO { } // namespace SOME_RANDOM_MACRO and clang-tidy suggested: namespace SOME_RANDOM_MACRO { } // namespace macro which is obviously wrong. During review we decided that it would be a good idea (apparently not so good) to detect macro expansions and force users to use only macro definitions. This could be useful to avoid mixing macro definitions with macro expansions. @alexfh, @gribozavr2, @aaron.ballman I think the best way out here is just to implement the basic fix for the above problem and only allow to use macro definition in closing comment and skip checking macro expansions completely. If you agree I will provide a patch for that. Comment Actions alexfh already provided a fix, please review and ensure that it fixes your case: https://reviews.llvm.org/D70974 |
Missing a full stop at the end of the sentence.