Bazel silently misbehaves if cxx_builtin_include_directories includes the output base

[EdSchouten]

Description of the bug:

Imagine a situation where on macOS you need to use C++ SDKs that are not managed by Bazel itself, but are stored in disk images that are mounted somewhere under /Volumes/. To make this work, you add /Volumes/ to cxx_builtin_include_directories. Now imagine that for some reason you also decide to place your Bazel output base inside of a disk image that is mounted under /Volumes/ (e.g., because you want it to be case sensitive on a machine whose root file system is case insensitive). In other words: the output base becomes covered by cxx_builtin_include_directories.

We have observed that if this happens, Bazel's C++ dependency graph pruning (using the .d files) becomes far too aggressive, leading it to falsely strip actual dependencies. This leads to Bazel not recompiling certain source files when changes to header files are made. In the best case this results in unexpected linker errors. In the worst case you get binaries that misbehave at runtime.

The problem disappears if --nocc_dotd_files is passed in, as this prevents Bazel from doing any pruning.

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.

1. Declare a custom C++ toolchain that has an overly broad cxx_builtin_include_directories (e.g., containing "/").
2. Build a C++ application with some library dependencies.
3. Make changes to some header files.
4. Rebuild the C++ application.
5. Stuff doesn't get rebuilt.

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

9.0.1, 9.1.0, and today's master

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?

If this is considered to be bad practice or a user error, then Bazel should at least throw a warning or an error.

[EdSchouten]

Giving it some more thought, I think this can be treated as a quality of implementation issue. My assumption would be that processing of .d files would ideally go as follows:

for path in dependencies_in_dotd:
    if path.isabs():
        if cxx_builtin_include_directories.contains_prefix_for(path):
            # Ignore this, as it's part of an externally managed SDK.
            pass
        else:
            fail("Attempted to include header file that does not belong to the SDK")
    else:
        register_actual_header_dependency(path)

However, based on the issue I encountered my gut feeling is that the algorithm more closely resembles the following:

for path in dependencies_in_dotd:
    if not path.isabs():
        path = path.realpath()
    if cxx_builtin_include_directories.contains_prefix_for(path):
        # Ignore this, as it's part of an externally managed SDK.
        pass
    elif not path.has_prefix(output_base):
        fail("Attempted to include header file that does not belong to the SDK")
    else:
        register_actual_header_dependency(path)