Bazel Plugin Inteferes with CLion Code Analysis, Making CLion Report Nonexistent Errors

[erinacio]

Description of the bug:

After upgraded Bazel for CLion plugin to 2024.03.12.0.1-api-version-233, cleared CLion cache and did a full project sync, CLion can't correctly analysis my C++ project, reporting nonexistent problems.

The project builds.

CLion seems to recognize a legitimate C++ source file as C file (and this error is reported on a comment):

and reports a lot of errors:

Other files seems don't have such funny error, but still have issues like failed to parse a FMT_COMPILE macro.

All those issues disappeared after downgraded the Bazel plugin to 2024.02.27.0.1-api-version-233, cleared CLion cache and did a full project sync.

Which category does this issue belong to?

CLion

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I'm still struggling understanding this particular problem. Seems that not all .cc source files are affected by this problem. Because the project is proprietary (for now) I can't share you with the exact code that triggers such problem.

Which Intellij IDE are you using? Please provide the specific version.

CLion 2023.3.4

What programming languages and tools are you using? Please provide specific versions.

C++, clang 17.0.6 (from archlinux repo), Bazel 6.2.0

What Bazel plugin version are you using?

2024.03.12.0.1-api-version-233

Have you found anything relevant by searching the web?

• I searched GitHub issues with CLion or C++ tags and no relevant result showed.
• I have no permission to view the email threads.
• Most Google search results are totally irrelevant.

Any other information, logs, or outputs that you want to share?

I edited the clion.sh launcher script and added these three lines to it:

export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
export BAZEL_USE_CPP_ONLY_TOOLCHAIN=1

I compared the "Show Compiler Info" result between two Bazel plugin versions, and found that the new Bazel plugin inserted a whole bunch of things like

......
+       -ibazelasio/detail/assert.hpp=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_chriskohlhoff_asio/asio/detail/assert.hpp
+       -ibazelasio/detail/atomic_count.hpp=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_chriskohlhoff_asio/asio/detail/atomic_count.hpp
+       -ibazelasio/detail/base_from_cancellation_state.hpp=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_chriskohlhoff_asio/asio/detail/base_from_cancellation_state.hpp
+       -ibazelasio/detail/base_from_completion_cond.hpp=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_chriskohlhoff_asio/asio/detail/base_from_completion_cond.hpp
+       -ibazelasio/detail/bind_handler.hpp=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_chriskohlhoff_asio/asio/detail/bind_handler.hpp
+       -ibazelasio/detail/blocking_executor_op.hpp=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_chriskohlhoff_asio/asio/detail/blocking_executor_op.hpp
......
+       -ibazelinclude/gsl/algorithm=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_microsoft_gsl/include/gsl/algorithm
+       -ibazelinclude/gsl/assert=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_microsoft_gsl/include/gsl/assert
+       -ibazelinclude/gsl/byte=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_microsoft_gsl/include/gsl/byte
+       -ibazelinclude/gsl/gsl_algorithm=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_microsoft_gsl/include/gsl/gsl_algorithm
+       -ibazelinclude/gsl/gsl_assert=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_microsoft_gsl/include/gsl/gsl_assert
+       -ibazelinclude/gsl/gsl_byte=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_microsoft_gsl/include/gsl/gsl_byte
+       -ibazelinclude/gsl/gsl=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_github_microsoft_gsl/include/gsl/gsl
......
+       -ibazelinternal/spinlock.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/spinlock.h
+       -ibazelinternal/spinlock_wait.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/spinlock_wait.h
+       -ibazelinternal/string_constant.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/strings/internal/string_constant.h
+       -ibazelinternal/sysinfo.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/sysinfo.h
+       -ibazelinternal/thread_identity.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/thread_identity.h
+       -ibazelinternal/throw_delegate.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/throw_delegate.h
+       -ibazelinternal/tsan_mutex_interface.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/tsan_mutex_interface.h
+       -ibazelinternal/unaligned_access.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/unaligned_access.h
......

to the "Compiler switches" section. All other sections remain unchanged (orders may be changed as I sorted them first to do a diff).

[satyanandak]

Hi @erinacio, could you please upgrade the bazel version to 7.1.1 and retry ? Please let us know if you see the same issue.

[erinacio]

Hi @erinacio, could you please upgrade the bazel version to 7.1.1 and retry ? Please let us know if you see the same issue.

It failed to build one of the dependencies. I'm not a bazel guru and the bazel guru in my team is busy working on another project. I suspect we can't easily upgrade bazel version now.

[erinacio]

Could anyone explain what these -ibazel... options do and how I could revert this particular change from the old version to see if that's the root cause?

[erinacio]

CLion 2024.1 was released and I updated and the behavior somehow changed.

The legacy language engine refuses to work on the particular source file (http_headers_test.cc). All tokens except C++ keywords are plain white. Completion also doesn't work. Using Ctrl-Space to trigger completion only shows me a dropdown box with a loading circle.

However, the new ReSharper engine somehow, works? All tokens are correctly colored. Code inspection works. Code completion works. No more nonexistent error reported.

For now I suspect that that -ibazel feature is added solely for the ReSharper engine, as it just breaks the legacy engine. However, seems that this feature is turned on regardless of if ReSharper engine is enabled. It's even enabled on 2023.3 versions which don't have the ReSharper engine.

The ReSharper engine is not enabled by default in CLion 2024.1, so I think this regression may still worth being fixed, at least until the ReSharper engine is enabled by default.

[ujohnny]

@erinacio the -ibazel feature was added to the old engine (to be precise to clangd, and clangd is not used for navigation when resharper engine is enabled). This is caused by #6007. Unfortunately we've accidentally removed the feature switch and indeed the only workaround is to use Resharper engine. But it can't be used with 2023.3. cc @LeFrosch

[ujohnny]

@erinacio does the issue exist after non-incremental sync?

[erinacio]

@erinacio does the issue exist after non-incremental sync?

The issue first happened when I cleared the CLion cache and did a full sync with 2024.03.x plugin. The issue didn't disappear after I did more full syncs, regardless of if I cleared the CLion cache or not.

[LeFrosch]

@erinacio Hi, it is possible to disable the collection of the -ibazel flags during sync with this flag:

bazel.cpp.sync.workspace.collect.include.prefix.hints.disabled

Also I tired to reproduce the analysis errors but I was not able to do so. How many of the -ibazel mappings can you find in the compiler info roughly?

[erinacio]

@erinacio Hi, it is possible to disable the collection of the -ibazel flags during sync with this flag:

bazel.cpp.sync.workspace.collect.include.prefix.hints.disabled

Also I tired to reproduce the analysis errors but I was not able to do so. How many of the -ibazel mappings can you find in the compiler info roughly?

I tried adding the following line to the idea.properties of CLion and code analysis works again with CLion 2024.1 and Bazel plugin 2024.03.26.0.1-api-version-241, with the legacy clangd engine.

bazel.cpp.sync.workspace.collect.include.prefix.hints.disabled=true

---

For the particular source file http_headers_test.cc, it has 933 -ibazel flags:

% pbpaste | grep -F -- -ibazel | wc -l
933

Among which, -ibazel flags refer to files in these external packages:

% pbpaste | grep -F -- -ibazel | grep -oE '/external/[^/]+/' | sort | uniq -c
    677 /external/com_github_chriskohlhoff_asio/
     13 /external/com_github_fmtlib_fmt/
    103 /external/com_github_gabime_spdlog/
      9 /external/com_github_magic_enum/
     15 /external/com_github_microsoft_gsl/
      1 /external/com_github_nodejs_llhttp/
     67 /external/com_google_absl/

pbpaste is a simple wrapper of wl-paste, which sends wayland clipboard content to stdout. I manually copied all compiler flags from the compiler info page.

[ujohnny]

My apologies for closing this too early. We provided a workaround in the related PR, you can set bazel.sync.resolve.virtual.includes to false to disable these -ibazel hints and use the old logic with implicit heuristics to find strip_include_prefix headers. But I guess we still would like to find the reason why -ibazel does not work for you.

[erinacio]

My apologies for closing this too early. We provided a workaround in the related PR, you can set bazel.sync.resolve.virtual.includes to false to disable these -ibazel hints and use the old logic with implicit heuristics to find strip_include_prefix headers. But I guess we still would like to find the reason why -ibazel does not work for you.

May I have any hint about what might be the cause of this issue? I don't have detailed idea about how clangd-based code inspection works on CLion and how bazel plugin affects that, so it's hard for me to find out what actually went wrong in my case. I tried many times producing a MRE and in all these cases the code inspection just worked without any problem.

[LeFrosch]

Sorry we don't know what cause clangd to break when the -ibazel flag are used in your project. However, I can roughly explain to you how the -ibazel flags are supposed to work with clangd.

The idea behind the -ibazel flag is to provide a mapping from the source path (the path used in your source code) to the actual file path to clangd. For instance this line

-ibazelinternal/unaligned_access.h=/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/unaligned_access.h

creates a mapping from

internal/unaligned_access.h

to

/cache/bazel/_bazel_lk/4faefe1c41672e714c7262fd5f5f7a1c/external/com_google_absl/absl/base/internal/unaligned_access.h

This would allow clangd to resolve references to this file in your source code. When creating these mappings we take things like strip_include into consideration.

[ujohnny]

and let me add that we're trying to check if the right side a project file, then we map into the project rather than bazel cache. or to external if not.

@erinacio can you drop us a simple project that uses libfmt from cc file for example? or from cpp/cxx, but maybe with some other cc files in project.

[erinacio]

and let me add that we're trying to check if the right side a project file, then we map into the project rather than bazel cache. or to external if not.

@erinacio can you drop us a simple project that uses libfmt from cc file for example? or from cpp/cxx, but maybe with some other cc files in project.

This is a simple project that I used to try to reproduce this issue (and failed to reproduce), with fmtlib and asio as external dependencies. I almost copied the http_archive from the build file of the original project, but slightly modified to adapt them to the simple project.

bzlexp.zip

[LeFrosch]

We disabled these changes by default with #6534. If you still experience this issue, please reopen this ticket.

Edit: The fix is available in v2024.07.02-RC-1