Incorrect `undeclared inclusion(s)` on Windows

[UebelAndre]

Description of the bug:

I noticed this in OpenSSL in BCR and have some data for it here: https://github.com/raccoons-build/bazel-openssl-cc/pull/45#issuecomment-3499772102

 ERROR: C:/users/runneradmin/_bazel_runneradmin/hjc222nr/external/openssl+/test_bazel_build/BUILD.bazel:28:11: Compiling external/openssl+/test_bazel_build/includes_bh.cpp failed: undeclared inclusion(s) in rule '@@openssl+//test_bazel_build:includes_bn':
this rule is missing dependency declarations for the following files included by 'external/openssl+/test_bazel_build/includes_bh.cpp':
  'external/openssl+/include/openssl/opensslconf.h'

Essentially we can see in a cquery that the header that Bazel claims is not a declared include is definitely directly passed to hdrs for the target.

cc_library(
    name = "crypto",
    # ...
    hdrs = [
        # ...
        "@openssl//:include/openssl/opensslconf.h",
        # ...
    ],
    # ...
)

I lack a Windows machine or sufficient context in the Java code to know what's going on here but this seems like a Bazel 9 bug as the targets work on Bazel 7 and Bazel 8.

Which category does this issue belong to?

C++ Rules

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

Use the following MODULE.bazel

bazel_dep(name = "openssl", version = "3.3.1.bcr.9")

Run the following command

bazel build @openssl

Which operating system are you running Bazel on?

Windows

What is the output of bazel info release?

release 9.0.0-pre.20251029.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

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

No response

[fmeum]

@bazel-io fork 9.0.0

[fmeum]

cc @meteorcloudy

[pcjanzen]

This will also reproduce on MacOS (and, I assume, linux as well) with --spawn_strategy=local.

Note that the referenced file opensslconf.h is both a source file and a generated file. The undeclared inclusion check has figured out that the compiler has included the source file, whereas it should have included the generated file (and would have in a sandboxed mode).

IMO the bug here is that 8.x did not fail in this case.

[UebelAndre]

I agree that should definitely be a failure but I also think it's perfectly valid have a generated file match the name of a source file. This seems like it should be supported.

[iancha1992]

@UebelAndre @fmeum I understand that this is a bug, but we are planning to release Bazel 9.0.0 this month or early next month. Since I don't see this fix being worked on, can we put the soft-release-blocker label and include this fix in the next release (9.1.0 in February/March)?

[UebelAndre]

Why isn't anyone working on the issue? If a fix isn't gonna be added, I think the change in behavior to rules CC should be gated behind an incompatibility flag to not block upgrading.

[fmeum]

@UebelAndre Are you able to run a bisect with bazelisk? I can look into fixing this.

[pcjanzen]

https://github.com/bazelbuild/bazel/commit/2dde0d53a3c867b3b862c951092b25bae623d409

and indeed, adding features = ["system_include_paths"] restores the Bazel 8.x behavior.

It appears that any file appearing in a system include directory is exempt from .d file validation, which seems bogus to me.

[fmeum]

Thanks for running the bisect. So openssl would have failed .d validation if it had been running, but it didn't due to being on the system include path? If that's the case, then this appears to be a desired consequence of the linked incompatible change.

Cc @keith

[meteorcloudy]

grpc probably had the similar problem and we had to use REPO.bazel to inject this feature for it: https://github.com/bazelbuild/bazel-central-registry/blob/950587f0751aed12cb1bc2d7a3cb934afbad23ea/modules/grpc/1.76.0.bcr.1/patches/add_repo_bazel.patch

[keith]

sounds like we should either

• fix the dep
• add that feature to the BUILD file upstream
• or pass --features=external_include_paths --host_features=external_include_paths

[pcjanzen]

@meteorcloudy while the change you linked should allow grpc to build successfully on windows, what it means is that you're picking up undeclared *.upb.h headers from grpc's src/core/ext/upb-gen source directory instead of the ones generated by @protobuf

[meteorcloudy]

@pcjanzen Indeed it's probably not the best solution, feel free to send a proper fix to grpc.