- User Since
- Jan 17 2023, 12:16 PM (9 w, 1 d)
Feb 3 2023
Though I did find that it inserted more than one NOLINT comment for a templated function, probably due to multiple warnings being issued for the same violation.
I just tried this out on a somewhat larger scale - I built all of CMake with this flag enabled, and it found a number of clang-tidy violations and added NOLINT comments to silence them. Worked like a charm.
Added virtual destructor to HeaderGuardStyle.
CI on all seven commits in this stack looks good.
Removed comma from documentation.
Updated with review feedback.
@aaron.ballman @njames93 could you guys please take another look at this?
Feb 2 2023
Any chance we could get the rest of LLVM upgraded to 3.20.0 as well? I'd like to get Ninja Multi-Config working.
Feb 1 2023
Rebased onto D143099.
Added tests and fixed assertion error in release build.
Jan 31 2023
Fixed crash when warning doesn't have associated location.
Jan 27 2023
Jan 26 2023
Closed in favor of D142673.
Refactored to use HeaderGuardStyle.
Jan 24 2023
Printed Introducer parameter in Pragma methods.
Added Introducer parameter to Pragma callbacks.
Jan 21 2023
Jan 19 2023
Basically, anything that extends HeaderGuardCheck (or HeaderGuardBase from D142121) is really just a fancy configuration option, rather than a separate check, and should be treated as such. My proposal is this:
In terms of a "generic check", there is already the HeaderGuardCheck, but that has to be extended to be specific to the project's naming convention. And I don't think there can be a generic check that converts #pragma once to a header guard - when it adds the header guard, what does it name it? It has to know the project's naming convention. If we want a check that replaces #pragma once with a header guard, our best bet would be modifying HeaderGuardCheck to do this, since it already does most of the needed work. However, such functionality is orthogonal to my proposal here.
Yes, this is for D142123. However, even if that doesn't land, I'd still like to land this. We use the code from D142123 in CMake's CI system, and getting it to work without this change resulted in a massive amount of code duplication. This refactoring would allow us to eliminate such duplication on our end.
We have this check in a custom clang-tidy module that runs on CMake's CI system. Other people have also sought out such a check, and I figured it made sense to upstream it instead of keeping it stuck in our CI. Even though it's not standard, other people might still want to use it. Perhaps there's a better category for it than modernize?
Jan 18 2023
Jan 17 2023
WIP - currently updating the tests for pp-trace and in the process debugging an issue with the location of the #endif hash.