Bazel protobuf generated pb.h files are not indexed

[baibinghere]

Description of the bug:

Remote SSH Development Environment. Bazel installed on Host. Imported as bazel project. Verified the pb.h files are generated in ./bazel-bin/, ./bazel-out/ folders. When including headers such as configs/node_config.pb.h, CLion IDE complains 'configs/node_config.pb.h' file not found, while it should be referenced either to the file under ./bazel-bin/config/node_config.pb.h or to the protobuf definition file.

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

CLion 2025.1.3

What Bazel plugin version are you using?

2025.06.24.0.1

[baibinghere]

Is there any way to find the Bazel plugin logs?

[baibinghere]

Hi team, I just tested an older version with CLion 2025.1.3. It is working:

The *.pb.h files can be correctly referenced to bazel-out/*.pb.h.

[grefab]

Same here. Last version that works for me in CLion is v2025.05.27. All after that (beta and stable) fail to index the auto-generated *.pb.h files.

If it helps: After downgrading the plugin, it needs a compile to have the files indexed.

[ujohnny]

@grefab so the version 06.10 does not work for you, is it correct?

[ujohnny]

I suspect this could be caused by #7701.

[grefab]

@grefab so the version 06.10 does not work for you, is it correct?

Correct. I tried 06.10, 06.24 and 07.08, all fail at indexing *.pb.h. 05.27 works fine.

[grefab]

Here you can find a minimal example to reproduce: https://github.com/grefab/7794

[ujohnny]

Brief update from our side:

1. This is indeed caused by #7701
2. Here's a 1 line change that "fixes" the issue

diff --git a/cpp/src/com/google/idea/blaze/cpp/HeaderRootTrimmerImpl.kt b/cpp/src/com/google/idea/blaze/cpp/HeaderRootTrimmerImpl.kt
--- a/cpp/src/com/google/idea/blaze/cpp/HeaderRootTrimmerImpl.kt	(revision a4292e3d9034fa65e5743095a3650f3b90dfc16c)
+++ b/cpp/src/com/google/idea/blaze/cpp/HeaderRootTrimmerImpl.kt	(date 1752524360469)
@@ -112,7 +112,7 @@
   for (directory in possibleDirectories) {
     val add = when {
       // never allow the bazel-bin as a header search path
-      path.isBazelBin(projectData.blazeInfo) -> false
+      path.isBazelBin(projectData.blazeInfo) -> true
 
       // if it is not an output directory, there should be now big binary artifacts
       !path.isOutputDirectory(projectData.blazeInfo) -> true

3. Why "fixes" is in quotes: a. In the past 2 months we were trying to address performance issues with the bazel plugin. One of them was caused by bazel-bin added as a header search path. Resharper engine would like to perform a greedy processing for the directory, but bazel-bin contains a lot of artifacts (incl. binary) in it, that causes CLion performance to heavily degrade after build is performed. So changing true to false addresses this issue, but brings back the old one.
4. It's partially caused by protobuf implementation here https://github.com/protocolbuffers/protobuf/blob/74211c0dfc2777318ab53c2cd2c317a2ef9012de/bazel/common/proto_common.bzl#L185 as bazel-bin is used as a default output root for all these generated headers.
5. By reading the code around I noticed some _virtual_imports mentions (to not accidentally mix with _virtual_includes), that makes some things "better", so for the given example I moved proto files to foo and then added strip_import_prefix (again, not strip_include_prefix, BUT the generated includes are in bin/_virtual_includes/proto)

proto_library(
    name = "proto",
    srcs = [
        "foo/Foo.proto",
    ],
    strip_import_prefix = "foo",
)

6. With (5) the "fix" from (2) is not required and everything works fine out of the box. Though I admit writing bazel files to convince IDE isn't the correct choice.
7. A similar option import_prefix could be used, but then all include statements must include file with a some prefix provided.
8. tbh it would be really nice to have this fixed in protobuf, but I'm unsure if it's possible and then the question of old versions support is here too.

edit: updated link to protobuf

[grefab]

Thanks for the update! Sounds like a deeper issue. Please let me know if I can support in any way.

[LeFrosch]

Thanks @ujohnny for the great summary of the problem. I just want to add that this problem extends a little further, if you also have generated headers in a cc_library without a strip_include_prefix or include_prefix, these headers are also placed directly into bazel-bin.

Let's add a registry flag to allow bazel-bin as a header search path again and enable it by default for now. I think the proper solution here is to maintain a custom cache of generated sources which we refresh on sync. Then we can use this cache as include paths and avoid bazel-bin entirely. But I think this will take more time and this issue seems quite sever.

[ujohnny]

@LeFrosch agree 👍

[LeFrosch]

We now have a proper fix for this, the header cache. You can try enabling it with the following registry key: bazel.cpp.header.cache.enabled Please do a non-incremental resync after switching the key.

We will also enable it by default soon once we received more feedback.