Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bazel 7 and Sonarlint don't play nice #159

Open
Attempt3035 opened this issue Jan 9, 2024 · 4 comments
Open

Bazel 7 and Sonarlint don't play nice #159

Attempt3035 opened this issue Jan 9, 2024 · 4 comments

Comments

@Attempt3035
Copy link
Contributor

Hey all!
I've just spend a few hours endlessly searching to figure out why on earth Sonarlint randomly stopped working. My setup uses vscodium, clangd and sonarlint for quite a nice c++ development setup. After much searching, I figured out the issue was in the compile commands, which had changed not due to an update in this tool, but instead from when I updated from bazel 6.4.0 to 7. The key difference is this:
Compile commands with this tool AND BAZEL 6.4 ends up having clang as the compiler on my setup (first line of args)
"arguments": [ "clang",
Where as Bazel 7 ends up as:
"arguments": [ "external/bazel_tools~cc_configure_extension~local_config_cc/cc_wrapper.sh",

Sonarlint says "I have no idea what this compiler is, I won't lint any of your code anymore"
I don't think it's on Sonarlint to come up with a solution, and Bazel presumably has a good reason for having the wrapper in-between? Has anyone else come across this issue yet, and any ideas on how we might be able to solve it? Maybe we can extract what compiler the wrapper decides to use, or guess via some other method?

At the moment I've got a .bazelversion file with contents 6.4.0 so that bazelisk gets everything playing nicely for now😅

@cpsauer
Copy link
Contributor

cpsauer commented Jan 10, 2024

Ah, shoot. clangd can penetrate simple wrappers like this with --query-driver, but that doesn't mean it'd extend to other tools. (You can see some notes about the unwrapping we do in more problematic cases in _apple_platform_patch.) Thanks for reporting, Luke. We should unwrap them as part of our de-bazeling.

There're some flags you can add that reveal the underlying compiler...someone else had proposed them in a PR that didn't end up getting merged because --query_driver was good enough from them. Could I ask you to take a look at #40 and see if you can repurpose the code (and clean it up a little)? That way we can get you back on Bazel 7. (Or rolling, which I'd recommend to get the latest fixes :)

(Would also like to know if this is Apple or Linux where you're running into the issue.)

@cpsauer
Copy link
Contributor

cpsauer commented Jan 10, 2024

One other thought: We'll need to be careful to not unwrap emcc.sh by mistake.

@Attempt3035
Copy link
Contributor Author

Thank you for the detailed reply! It's a little over my head at the moment, I'll try and look into everything you've pointed out over the next couple of weeks and see what I can propose! Also, that was on Apple (newest os, M2). Only occurred now as I wasn't using bazelisk (I had bazel straight through brew), and as soon as I installed bazelisk it updated to 7.

@cpsauer
Copy link
Contributor

cpsauer commented Jan 10, 2024

Thanks for being down to help!
(Strong rec for bazelisk--and Bazel rolling, so you get bug fixes faster!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants