[PATCH] D34654: Allow passing a regex for headers to exclude from clang-tidy

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

> In our project we want to do something like include src/.*.h but exclude src/some-thirdparty/.*.h.

There are at least two other possibilities to handle this use case.

The first one is to extend the way clang-tidy handles per-directory configs. Currently, for each translation unit clang-tidy takes the configuration for the main file of the translation unit and uses the Checks option found in this configuration to filter diagnostics coming from the main file as well as from the headers included by the translation unit. In a better world, it would take the configuration for the header where the diagnostic originates and thus allow a more source-centric way of controlling the set of diagnostics it displays. For example, consider this setup:

  a/.clang-tidy: Checks=-*,check1,check2
  a/a.cpp: #include a/a.h, #include b/b.h, #include third-party/c.h
  a/a.h
  b/.clang-tidy: Checks=-*,check2,check3
  b/b.h
  third-party/.clang-tidy: Checks=-*
  third-party/c.h

Let's assume that each of a/a.h, b/b.h, third-party/c.h and a/a.cpp contain code that triggers check1, check2 and check3. Currently, when run on a.cpp without `-header-filter`, clang-tidy would only output check1 and check2 from a.cpp. `-header-filter=.*` will result in check1 and check2 diagnostics from all the files.

If we change clang-tidy to apply the most relevant local configuration to the generated diagnostics (and get rid of `-header-filter` altogether, or set it to `.*` by default), in the case above it would output check1 and check2 from a/a.cpp and a/a.h, check2 from b/b.h (since we don't even run check3 on the code, and check1 gets filtered out), and no diagnostics from third-party/c.h, since we filter out check1 and check2 according to the local configuration. This seems like a more logical and useful behavior, however, when implementing this we'll have to make sure configuration retrieval doesn't become a bottleneck (FileOptionsProvider already implements some sort of caching, but we'd have to carefully benchmark it on large translation units with tons of diagnostics).

The second way to handle this use case is possible on a different level: one can run clang-tidy over the whole project with `-header-filter=.*` and then filter the results and use a specialized tool to display them, e.g. https://github.com/Ericsson/codechecker. I'm not sure though whether this suits your needs or is an overkill.


Repository:
  rL LLVM

https://reviews.llvm.org/D34654