Add option to disable header inclusion check

[froody]

Description of the feature request:

In my CI environment, I see builds randomly fail with errors like this (with protobuf-29.3 imported via MODULE.bazel).

this rule is missing dependency declarations for the following files included by 'src/google/protobuf/any_lite.cc':
  'bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/protobuf~/src/google/protobuf/_virtual_includes/protobuf_lite/google/protobuf/port.h'

The randomness of this error plus the need to clean the bazel cache (which doesn't always make the error go away) wastes countless hours of time. I would love to have a flag like --incompatible-ignore-header-checks which made these errors non-fatal

Which category does this issue belong to?

C++ Rules

What underlying problem are you trying to solve with this feature?

Builds failing due to false positives from header inclusion checks

Which operating system are you running Bazel on?

Ubuntu 22.04

What is the output of bazel info release?

7.4.0

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 ?

<private repo>

Have you found anything relevant by searching the web?

No response

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

No response

[pzembrod]

I don't quite understand the randomness of the build failures you are reporting. If these checks fail randomly, it would seem to me that something larger is amiss, and skipping the error messages at one point (in this case the header check) via a flag is not something I would feel comfortable with at this point.
Can you describe the randomness you experience a bit more?

[burnpanck]

While I do not know the OP's specific case for failed inclusion check, there is a long-standing issue (#14346) that Clang sometimes (i.e. depending the specific invocation parameters, not the local weather) inserts absolute paths into .d files, causing the inclusion check to fail. I now found a new inclusion validation bug (#26150) which may well be just another case of absolute paths in .d files, which now blocks me from using #embed. So here, too, such an option as the OP requests would help at least in the short term. It may be a good "band-aid" if that inclusion validation is so sharp-edged to cause issues repeatedly and over years (even though when it actually works, its a great thing!).

[keith]

iiuc today dotd files are used for 2 things:

1. doing compilation avoidance when headers that are in your deps but do not appear in the .d file are changed, you know the current source file doesn't need to be rebuilt. This seems like a pretty important optimization
2. erroring in the case that a file shows up in the .d file that isn't in your deps. This is a hermiticity check

Currently you can disable both of these features in a few different ways. You can pass --cc_dotd_files=false, or you can set features = ["no_dotd_files"] (maybe you can scope this to a specific target / REPO.bazel)

but you can't only disable #2, so this probably isn't perfect. seems to me like we could actual repurpose those flags to only disable the validation, since the other feature doesn't really seem as important to be disable-able to me (a toolchain that didn't have the config for it would still mean it was disabled I guess)