[NFC][clangd] exclude test data from clang-tidy

[kuhnel]

Summary

Adding .clang-tidy files to exclude test data from clang-tidy checks. Otherwise these create false positives.

[sammccall]

Hmm, clang-tidy should only be running on entries in compile_commands.json. are these files listed somehow?

(I don't like the idea that every test inputs dir may need to contain a scattering of files to disable tools. At most we should be able to do this under test/)

[kuhnel]

In D113902#3131707, @sammccall wrote:

Hmm, clang-tidy should only be running on entries in compile_commands.json. are these files listed somehow?

No, they are not.

The question is:
Do the tools our contributors use care about this? This is not the default behavior of clang-tidy, it's rather implemented in a LLVM-specific wrapper script. So do we require our contributors to use that script to check their code?

I was playing with the VS Code extension to see the findings right in the IDE and that calls clang-tidy directly. So it ignores compile_commands.json

[sammccall]

Details below, but TL;DR is running only on files in compile_commands.json is definitely the established way to analyze a project.
If you're proposing a *change* then that might be worth considering, but this probably isn't the place: mailing lists are more public and offline is higher-bandwidth :-)

In D113902#3137311, @kuhnel wrote:

In D113902#3131707, @sammccall wrote:

Hmm, clang-tidy should only be running on entries in compile_commands.json. are these files listed somehow?

No, they are not.

The question is:
Do the tools our contributors use care about this? This is not the default behavior of clang-tidy, it's rather implemented in a LLVM-specific wrapper script. So do we require our contributors to use that script to check their code?

---

A few things to unpack here:

• contributor status quo: our contributors mostly don't currently run clang-tidy, and we don't require them to.
• clang tools in general: when running tools on a codebase, we use the CDB to define the scope of the sources as well as to ensure we're only running on sources with reliable flags.
• clang-tidy proper. Most clang tools support --executor=all-TUs which iterates over the CDB to run on a project. It looks like clang-tidy does not have this, only explicitly running on one file at a time.
• wrapper script: I assume you're talking about run-clang-tidy.py? It provides the --executor=all-TUs behavior (and parallelism) as an external script. This is not LLVM-specific, it's part of the clang-tidy apt package etc along with the clang-tidy binary.

I was playing with the VS Code extension to see the findings right in the IDE and that calls clang-tidy directly. So it ignores compile_commands.json

(In fact it doesn't quite, it'll use it to pick a best approximate set of flags via InterpolatingCompilationDatabase. clangd behaves the same way.)

But yes, there's a difference in behavior between what happens when you run a tool on a file (you get best effort, even if the file is unknown) vs when you run a tool on a project (you get only the files that are considered part of the project). This is pretty consistent: e.g. clangd will try to assist in editing any file, but will only index files in compile_commands.json.

[kuhnel]

thx for the explanation, makes sense
--> abandoning this change

clang-tools-extra/clangd/test/Inputs/.clang-tidy

+# disable the check on the test input data
+InheritParentConfig: true
+Checks: "-misc-definitions-in-headers,-llvm-header-guard,-clang-diagnostic-unused-variable"

clang-tools-extra/clangd/test/index-serialization/Inputs/.clang-tidy

+# disable the check on the test input data
+InheritParentConfig: true
+Checks: "-clang-diagnostic-non-virtual-dtor,-readability-identifier-naming"

clang-tools-extra/clangd/test/remote-index/Inputs/.clang-tidy

+# disable the check on the test input data
+InheritParentConfig: true
+Checks: "-misc-definitions-in-headers"