JonasToth added a comment. In https://reviews.llvm.org/D41648#965432, @aaron.ballman wrote:
> I think this check is going to be extraordinarily chatty. For instance, > macros are often used to hide compiler details in signatures, such as use of > attributes. This construct cannot be replaced with anything else because the > macro isn't defining an object or value. Another example where this will be > bad is for conditional processing where the macro is later used in a `#if`, > `#elif`, `#ifdef`, or `#ifndef` preprocessor conditional, as this also cannot > be replaced with a `constexpr` variable. Without handling things like this, I > don't see how this rule can provide utility to real world code. Do you have > ideas for how to handle these kind of situations? The check will only warn in the definition of the macro not the expansion. The guidelines are really strict with macros and explicitly state that program maniupulation is a bad thing. Having a macro without value, like header guards or compile time flag style things are not reported with this check. Other (valid) use cases require a NOLINT with this check. But i do not know how to figure out automatically what a macro is meant to do. I can introduce a whitelist for allowed macros. Furthermore i could make each use case a configurable option. E.g. forbidding constant definitions i still a good thing (imho). Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D41648 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
