[clang-tidy] HeaderFilterRegex in .clang-tidy is not applied consistently and depends on working directory

[PWVEC]

I've encountered a strange behavior regarding "HeaderFilterRegex" (other options might be affected as well...).
I've tested this with clang-tidy version 19.1.2.
With older versions (e.g. clang-tidy 18.1.2) HeaderFilterRegex works as expected, so this seems to be a new issue.

Given the following setup in a project:

.
└── src
    ├── .clang-tidy
    ├── external.h
    ├── internal.h
    └── main.cpp

With the following file contents:

$ cat src/.clang-tidy
Checks: "-*,modernize-use-trailing-return-type"
HeaderFilterRegex: '.*internal.*'

$ cat src/internal.h
int GetSomeValue();

$ cat src/external.h
int GetSomeLibValue();

$ cat src/main.cpp
#include "internal.h"
#include "external.h"

int GetSomeValue() { return 42; }

int main() {
  return GetSomeValue() + GetSomeLibValue();
}

The expectation is that when clang-tidy is run on "main.cpp", it will report the diagnostics for "internal.h" but not for "external.h".
But this does not work consistently. It seems relevant in which workding directory clang-tidy is invoked.

$ clang-tidy src/main.cpp 2>/dev/null
PATH/TO/PROJ/src/main.cpp:4:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
    4 | int GetSomeValue() { return 42; }
      | ~~~ ^
      | auto               -> int
PATH/TO/PROJ/src/main.cpp:6:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
    6 | int main() {
      | ~~~ ^
      | auto       -> int

No diagnostic is applied, i.e. the "HeaderFilterRegex" is essentially set to ''.
If I run clang-tidy in "src", then this works as expected (internal.h is reported, external.h is not):

cd src/ && clang-tidy main.cpp 2>/dev/null
PATH/TO/PROJ/src/internal.h:1:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
    1 | int GetSomeValue();
      | ~~~ ^
      | auto               -> int
PATH/TO/PROJ/src/main.cpp:4:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
    4 | int GetSomeValue() { return 42; }
      | ~~~ ^
      | auto               -> int
PATH/TO/PROJ/src/main.cpp:6:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
    6 | int main() {
      | ~~~ ^
      | auto       -> int

Notably, if I dump the configuration with "--dump-config" the resulting configuration is identical in both cases and it clearly sets "HeaderFilterRegex" to ".*internal.*".

[Deewiant]

As pointed out in #121969, this seems to have been introduced with #91400.

From what I can tell, the problem might be due to how the initialization of HeaderFilter was moved to the constructor of ClangTidyDiagnosticConsumer. Based on cursory inspection:

• The initialization of HeaderFilter now happens in this call:

  llvm-project/clang-tools-extra/clang-tidy/plugin/ClangTidyPlugin.cpp

  Line 42 in cd70802

  new ClangTidyDiagnosticConsumer(*Context, &Compiler.getDiagnostics());

  • Where it loads HeaderFilterRegex from ClangTidyContext::getOptions:

    llvm-project/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp

    Lines 316 to 319 in cd70802

    	if (Context.getOptions().HeaderFilterRegex &&
    	!Context.getOptions().HeaderFilterRegex->empty())
    	HeaderFilter =
    	std::make_unique<llvm::Regex>(*Context.getOptions().HeaderFilterRegex);

• But ClangTidyContext::setCurrentFile is called only in here, a bit later:

  llvm-project/clang-tools-extra/clang-tidy/plugin/ClangTidyPlugin.cpp

  Line 50 in cd70802

  Vec.push_back(Factory.createASTConsumer(Compiler, File));

  • In which:

    llvm-project/clang-tools-extra/clang-tidy/ClangTidy.cpp

    Line 409 in cd70802

    Context.setCurrentFile(File);

• And ClangTidyContext::setCurrentFile is the place where the options for the specific file are loaded:

  llvm-project/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp

  Line 239 in cd70802

  CurrentOptions = getOptionsForFile(CurrentFile);

Previously, HeaderFilter was initialized in the call chain from ClangTidyDiagnosticConsumer::HandleDiagnostic, so definitely after the context had seen all the options.

Again, this is based on a quick look, and I'm not very familiar with the codebase so I don't know if this analysis holds water at all. (For example: is getOptionsForFile actually even related to the .clang-tidy file? It sounds like it to me, but I haven't dived that deep.) Hopefully this is at least a helpful hint and not complete misdirection.

[drobilla]

I'm also having this problem. It seems that ExcludeHeaderFilterRegex is broken in the same way (so you can't work around the issue by inverting the pattern in the configuration file).

[Wheest]

I might be facing this issue also. I've got a reproducible repo Wheest/clang-tidy-issue, where we don't want to run clang-tidy on any files under external.

And yet with my config., I still get

./external/extern_proj/funky.hpp:3:15: error: static assertion failed due to requirement '201703L == 202302L': Expected to be compiled with C++23 [clang-diagnostic-error]
    3 | static_assert(__cplusplus == 202302L, "Expected to be compiled with C++23");
      |               ^
note: expanded from macro '__cplusplus'
Found compiler error(s).

Version:

clang-tidy --version
Ubuntu LLVM version 18.1.3
Optimized build.

[jmcclellan-figma]

@Wheest static_asserts are compilation errors will always be shown regardless of HeaderFilterRegex.

Here's a minimal repro for this issue:

q/x.cpp

#include "x.h"

q/.clang-tidy

HeaderFilterRegex: '.*'

q/x.h

#warning "Test"

run: clang-tidy q/x.cpp

EXPECTED: warning is shown

ACTUAL: warning is suppressed because HeaderFilterRegex is being ignored

Note that before #91400, or if #91400 is reverted, we get the expected behavior.

This caused us to accidentally stop linting all header files after upgrading clang-tidy and seems like a rather serious issue!

[carlosgalvezp]

Strange, we are running latest trunk and do not observe this issue...

Edit: that's probably because we have the .clang-tidy file at the root instead of a subfolder.

[tearfur]

@carlosgalvezp I do have a reproducible example on 316bb89 at #133453 (comment).

[carlosgalvezp]

Yes, I can repro on our side as well.

[carlosgalvezp]

Actually it doesn't even work having all files at the root. HeaderFilterRegex is completely ignored?!

[carlosgalvezp]

I believe the linked PR should fix all the related issues, but it'd be great if you guys can test it!

[jmcclellan-figma]

I believe the linked PR should fix all the related issues, but it'd be great if you guys can test it!

Pardon my ignorance but is there a way to get a pre-built clang-tidy from a PR? Otherwise I can build and test - reading the code it does look like it would solve it

[carlosgalvezp]

Pardon my ignorance but is there a way to get a pre-built clang-tidy from a PR? Otherwise I can build and test - reading the code it does look like it would solve it

Unfortunately not, one needs to apply the diff and build from source.