[RFC] Teach check_clang_tidy.py the FileCheck --implicit-check-not option

Clang Frontend clang-tidy
1

As part of my work on another PR, I ran into the following issue.

I have several different suffixes in my tests which look something like the following:

Foo bar = baz; // test case
// CHECK-MESSAGES-SUFFIX-A :[[@LINE-1]]:11: warning: ...
// CHECK-MESSAGES-SUFFIX-B :[[@LINE-1]]:11: warning: ...

Foo bar = 42; // another test case
// CHECK-MESSAGES-SUFFIX-A :[[@LINE-1]]:11: warning: ...
// Will also trigger a warning for SUFFIX-B even though this test case is not relevant for SUFFIX-B

The problem is the following Either I can have one check_clang_tidy.py invocation check multiple prefixes via --check-suffixes:SUFFIX-A,SUFFIX-B, in which case the first test case will fail because a warning / fix can only be matched once, or I have two seperate check_clang_tidy.py invocations, one for each suffix, in which case the second test case will fail because of check_clang_tidy.py’s implicit FileCheck invocation with -implicit-check-not={{warning|error}}:, which reports if warnings are emited which are not matched.

To fix this, I’d like to teach check_clang_tidy.py FileCheck’s -implicit-check-not option and make it customisable via a CL argument.
I’ve verified that removing the “warning” part from the -implicit-check-not assignment above fixes my tests.

Would you be open to me submitting a PR here or is there a particular reason for check_clang_tidy.py setting the implicit-check-not option implicitly?

If I were to implement this, are there any particular preferences you have re: the implemenation?

2

which reports if warnings are emited which are not matched.

This is a strong requirement in clang-tidy tests. It’s equally important that clang-tidy emits the right warning at the right place, and also that it does not emit anything unexpected. I do not think this should be changed.

Typically your problem is solved by splitting the test into two separate .cpp test files. Would that work for you?

1 Like
3

Makes sense!

New files are what I wanted to avoid, but if that’s the accepted way to go, no objections from my side, of course. Thanks for your quick response, @carlosgalvezp!

1 Like
4

There’s always split-file to avoid new files. The tree has lots of examples.

1 Like
5

There’s always split-file to avoid new files. The tree has lots of examples.

Is this mentioned in the developer docs for getting started with clang-tidy?

6

We mention it in the testing guide for lit tests: LLVM Testing Infrastructure Guide — LLVM 21.0.0git documentation

2 Likes
7

Great, that should be sufficient!

1 Like
8

split-file worked. Thanks, @ilovepi!