Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clang-tidy/ClangTidyCheck.h | ||
---|---|---|
224 | Given the amount of new stuff added in c++11 and how many checks require c++11 I thought having a separate c++11 mode class would be a good idea, c++14/17 probably not so much though. |
clang-tools-extra/clang-tidy/ClangTidyCheck.h | ||
---|---|---|
210 | The final means that one cannot compose these. e.g., you cannot have a C-only check that also checks for other language options like whether CUDA is enabled or not, which seems unfortunate. | |
211 | This is not the behavior I would expect from the class name -- this is a C99 check, not a C check. Use !LangOpts.CPlusPlus instead | |
224 | I'm on the fence. It's certainly a plausible design, but I'm not certain I like having to go hunt in several places for "what are the conditions under which this check is enabled". Status quo is to always look in the check() function (or wherever the matcher is being registered), and the proposed changes (in other patches) is to move that to isLanguageVersionSupported() for a cleaner interface. I like that. But with this patch, now I have to either look at the base class or isLanguageVersionSupported() (and if we remove the final, then in both places as well). I think my preference is to go with isLanguageVersionSupported() and not use base classes. However, if there is more per-language functionality expected to be added to these base classes, then maybe this design would carry more water for me. |
I think my preference is to go with isLanguageVersionSupported() and not use base classes.
+1, I can see this working, but the introduction of new concepts does not seem like it pulls its weight given the tiny amount of boilerplate that they eliminate.
I suppose the only other way would be having another virtual function like inside the helper classes
virtual bool additionalLanguageConstraints(const LangOptions& LangOpts) const { return true; } bool isLanguageVersionSupported(const LangOptions &LangOpts) const final { return LangOpts.CPlusPlus && additionalLanguageConstraints(LangOpts); }
However I'm not a huge fan of that extra boilerplate
+1, I'm definitely against adding base classes for supported language versions. The increase in the API surface doesn't seem to pay off here.
The final means that one cannot compose these. e.g., you cannot have a C-only check that also checks for other language options like whether CUDA is enabled or not, which seems unfortunate.