Change all checks that take enums as configuration to use enum specific methods in ClangTidyCheck::OptionsView.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp | ||
---|---|---|
154 | Unsure about hardcoding the check-name as it could be ran under an alias. However there is no way for a ClangTidyCheck to get the name its ran as. ClangTidyCheck::CheckName is private, maybe a protected getter would be wise. | |
177 | I feel its safer not assuming the fix and instead letting the user modify their configuration, WDYT? |
I'm not too sure how many other checks are like this, but I feel that this functionality could maybe be brought out of this check and into the Options to let more checks that take enum like configurations to use it.
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp | ||
---|---|---|
149–151 | Some autos that don't have the type spelled out (also, a top-level const that can be dropped). | |
154 | I agree that we should not hardcode the name of the check. I actually wonder if a better approach here is to call Context->diag() to generate an actual diagnostic? | |
155 | acceptible -> acceptable | |
177 | Agreed -- we don't recover in Clang by assuming the fix to the command line option spelling, either. |
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp | ||
---|---|---|
149–151 | Copying from what was already there. | |
154 | A few issues with that approach, firstly the ClangTidyCheck doesn't expose the ClangTidyContext to any derived classes. the other issue is it requires a SourceLocation to emit a diagnostic, Passing an invalid SourceLocation effectively suppresses any output, likewise any other SourceLocation will just confuse users. |
Some autos that don't have the type spelled out (also, a top-level const that can be dropped).