Imagine that you’re attempting to enable a clang-tidy check on the CI for a large code base, but the check has a lot of outstanding violations. If the check has a fix available, no problem - simply run clang-tidy with the --fix or --export-fixes option, fix all of the existing code, and turn on the check in CI to ensure that no new violations creep in.
But what do you do if the check doesn’t have any fixes available? You can’t auto-fix all of the existing violations, and fixing them manually would take a very long time. Turning on the check would cause CI to always fail due to the large number of outstanding violations. But not turning it on means that new violations have the possibility to creep into the code.
I propose a solution to this problem: a clang-tidy fix mode that adds NOLINT comments to all existing violations it finds. Perhaps a command line option like --fix-mode=nolint. That way, the existing violations can be given a grace period to be fixed, the check can be enabled, and no new violations will be added.
As an example, consider the readability-identifier-length check, which doesn’t offer fixes, and the following code snippet:
void stuff()
{
int i = 0;
}
int i would violate readability-identifier-length. Imagine that there are thousands of such existing violations in your code base. Applying this new NOLINT fix option would turn this into:
void stuff()
{
// FIXME: NOLINTNEXTLINE(readability-identifier-length)
int i = 0;
}
Now you enable readability-identifier-length in your CI. It ignores the existing violation. But if you add a new one:
void stuff()
{
// FIXME: NOLINTNEXTLINE(readability-identifier-length)
int i = 0; // OK - this violation has been given a grace period to be fixed
int j = 0; // BAD - this violation is new and should not be introduced
}
then the check catches it and prevents it from being merged.
This feature would even add a TODO: or FIXME: prefix to the comment, as you can see in the example, to make it clear that the NOLINT should not be blindly copied around and should eventually be fixed.
What do you guys think about this? Would such a feature be welcome to clang-tidy?