[PATCH] D113902: [NFC][clangd] exclude test data from clang-tidy

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

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 <https://reviews.llvm.org/D113902#3137311>, @kuhnel wrote:

> In D113902#3131707 <https://reviews.llvm.org/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 <https://marketplace.visualstudio.com/items?itemName=notskm.clang-tidy> 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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113902/new/

https://reviews.llvm.org/D113902