Integration with bazel-compile-commands-extractor

[aminya]

bazel-compile-commands-extractor can generate compiled_commands.json files. I tried to hot patch the shell binary and add -p $PROJECT_ROOT to the clang-tidy command. However, it seems that still clang-tidy fails to find some headers.

https://github.com/hedronvision/bazel-compile-commands-extractor

The issue seems to be a mismatch between the config and compilation mode. bazel-compile-commands-extractor accepts extra flags like -- --config=debug --compilation_mode=dbg, but bazel_clang_tidy uses fastbuild by default.

[aminya]

I wonder if @cpsauer can help expose some of the things that bazel_clang_tidy needs. It seems that adding -p project_root doesn't fix the missing header errors.

[cpsauer]

Hey, @aminya!

My understanding is that clangd embeds clang-tidy these days, providing feedback as you edit if you want. So if you're already using clangd and generating a compile_commands.json with our tool, maybe that'd be a good way to get automated style feedback! Would love to hear your experience with that if you end up trying it.

[It looks like the goal of this project is a little different. They're looking to accommodate folks without a compile_commands.json (or clangd) and provide the style feedback as a build-style error. That's great stuff, but you've got the compile_commands.json and clangd already, I think. (All that said, I'm no clang-tidy expert (yet)--nor experienced with this project, so please tell me if I'm wrong or it there's a key integration we should be making.)]

Cheers,
Chris

[cpsauer]

P.S. For generated files, you'll want to have flags match when you build and when you use the tools! It's definitely a tricky thing to handle well for tool builders.

[aminya]

My issue with clangd's clang-tidy is that it doesn't show all the issues in the workspace to me. I need to open each file to trigger it. It also doesn't seem to work when a function is templated. I have to call that template in my tests to trigger those warnings. That's why running clang-tidy form CLI shows more warnings that are not shown by clangd.

[cpsauer]

Oh, got it. Makes sense.

To confirm, is the draw of this tool, then, over just running clang-tidy directly w/ the compile_commands.json, speed, since it takes care of caching via bazel?

Seems like some of the same questions remain, though: Is this tool designed to take a compile_commands.json file if you supply one?

[erenon]

It is not, there's no need for a json file

[cpsauer]

Hey, Thaler! Great to meet another Bazel toolmaker. Seems like a great thing you've built here.

[aminya]

I realized that with the help of hedronvision/bazel-compile-commands-extractor, running clang-tidy becomes just a matter of specifying the .cpp files (for example using git ls-files). It works accurately without any missing headers!

# first generate compile_commands.json
bazel run refresh_compile_commands -- --config=debug --compilation_mode=dbg

# run clang-tidy on cpp files
files=$(git ls-files --exclude-standard | grep -E '\.(cpp|c|cc|cxx)$')
clang-tidy -p ./ $files

# -p ./ specifies the path of the folder that compile_command.json is generated

It might be worthwhile adding this to the readme files.

[cpsauer]

@aminya, yeah! That's what I meant. You mean adding it to our README, yeah?
Glad to hear getting the compile commands solves the header things for you.
I assume it doesn't have the same caching as it would under this tool. But fast enough for you? Or are we trying to find a way to unite the two or add caching to our tool? Do we understand what was going wrong with the header finding here otherwise?

[cpsauer]

@aminya, I'm creating an issue to track over at hedronvision/bazel-compile-commands-extractor#52