custom .clang-tidy config not used for specific targets

[dotnwat]

Great project, thanks!

I'm using the following setup with the latest HEAD and bazel 7.3.1.

//.bazelrc
build:clang-tidy --aspects @bazel_clang_tidy//clang_tidy:clang_tidy.bzl%clang_tidy_aspect
build:clang-tidy --@bazel_clang_tidy//:clang_tidy_executable=@llvm_18_toolchain//:clang-tidy
build:clang-tidy --@bazel_clang_tidy//:clang_tidy_config=//:clang_tidy_config
build:clang-tidy --output_groups=report

//BUILD
filegroup(
    name = "clang_tidy_config",
    srcs = [".clang-tidy"],
    visibility = ["//visibility:public"],
)

What I'm seeing is that the .clang-tidy file in the root of our project is being used when I run

bazel build --config clang-tidy //...

But it is not being used when I build targets in subprojects like

bazel build --config clang-tidy //path/to/target

The method I used to verify this is to add an explicit syntax error into .clang-tidy. The former invocation fails as expected, the later ones do not. Presumably they are using the .clang-tidy file that ships with this project.

Is this expected? Is there a way to fix it?

[erenon]

Hi, thanks for the report. I fetched redpanda, but couldn't repro the issue. Bazel aquery shows that the config file is in the input set, and it is passed on the command line, regardless the target spec.

How do you know it isn't picked up?

[dotnwat]

@erenon thanks for taking a look.

How do you know it isn't picked up?

I put garbage into the .clang-tidy file, and observed the expected behavior of clang-tidy erroring out when parsing it when building //... but not //path/to/something/else.

Here is how I reproduced the issue:

echo "garbage" > .clang-tidy

Here is the version that fails, as expected (notice it chokes on .clang-tidy input):

nwatkins@acid:~/src/redpanda$ bazel build --config clang-tidy --nokeep_going //...
INFO: Invocation ID: 1815d4dc-666e-4cfe-b98f-3627050c2805
ERROR: /home/nwatkins/src/redpanda/src/v/cluster/tests/BUILD:13:25: Run clang-tidy on src/v/cluster/tests/leader_balancer_test_utils.h failed: (Exit 1): clang_tidy failed: error executing ClangTidy command (from target //src/v/cluster/tests:leader_balancer_test_utils) bazel-out/k8-fastbuild/bin/external/bazel_clang_tidy~/clang_tidy/clang_tidy bazel-out/k8-fastbuild/bin/external/toolchains_llvm~~llvm~llvm_18_toolchain/clang-tidy ... (remaining 40 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
/home/nwatkins/.cache/bazel/_bazel_nwatkins/31f1aa7012681f681e8d49a1818a8564/sandbox/linux-sandbox/10/execroot/_main/.clang-tidy:1:1: error: not a mapping
garbage

then in this version it passes

nwatkins@acid:~/src/redpanda$ bazel build --config clang-tidy --nokeep_going //src/v/bytes/...
INFO: Invocation ID: f9457115-81bd-4a90-96e2-4f298b50e896
INFO: Analyzed 11 targets (4 packages loaded, 632 targets configured).
INFO: From Executing genrule @@liburing~//:generate_headers:
INFO: Found 11 targets...
INFO: Elapsed time: 62.003s, Critical Path: 60.97s
INFO: 1022 processes: 365 disk cache hit, 628 internal, 29 linux-sandbox.
INFO: Build completed successfully, 1022 total actions
nwatkins@acid:~/src/redpanda$ echo $?
0

[dotnwat]

any thoughts on this? i'll probably have some time to take a closer look, but just wondering if this experiment is valid or not.

[erenon]

I'm unable to repro this. I can't build redpanda completely, so I removed the deps from src/v/bytes/BUILD: this way I can skip building openssh. Then I put garbage into .clang-tidy, and the following fails as expected:

$ bazel build --config clang-tidy --nokeep_going //src/v/bytes:all
INFO: Analyzed 8 targets (0 packages loaded, 0 targets configured).
ERROR: src/redpanda/src/v/bytes/BUILD:58:20: Run clang-tidy on src/v/bytes/random.cc failed: (Exit 1): clang_tidy failed: error executing ClangTidy command (from target //src/v/bytes:random) bazel-out/.../toolchains_llvm~~llvm~llvm_18_toolchain/clang-tidy ... (remaining 40 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
.../linux-sandbox/34/execroot/_main/.clang-tidy:1:1: error: not a mapping
garbage
^~~~~~~

I think there's something else going on with a different target. can you narrow down the target that doesn't fail as expected?