Wrong include path to Clang 16 on Windows

[stevenlr]

Description of the bug:

Building C++ with Clang 16.0.0 and Bazel 6 on Windows spits out "missing dependency declarations" for include files:

ERROR: .../BUILD:10:10: Compiling main.cpp failed: undeclared inclusion(s) in rule '//:main':
this rule is missing dependency declarations for the following files included by 'main.cpp':
  'C:/Program Files/LLVM/lib/clang/16/include/vadefs.h'

The clang lib is installed in C:/Program Files/LLVM/lib/clang/16, but Bazel uses clang-cl -v to detect the version used in the path, which is 16.0.0 here, hence wrongfully using the C:/Program Files/LLVM/lib/clang/16.0.0 path.

In external/local_config_cc/BUILD:

cc_toolchain_config(
    name = "clang_cl_x64",
    cpu = "x64_windows",
    compiler = "clang-cl",
    # ...
    msvc_env_include = "...;C:\\Program Files\\LLVM\\lib\\clang\\16.0.0\\include",
    msvc_env_lib = "...;C:\\Program Files\\LLVM\\lib\\clang\\16.0.0\\lib\\windows",
    # ...
    cxx_builtin_include_directories = [
        # ...
        "C:\\Program Files\\LLVM\\lib\\clang\\16.0.0\\include"],
    # ...
)

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

Use the following C++ file

#include <stdio.h>

int main()
{
    printf("Hello, world! " __clang_version__ "\n");
    return 0;
}

With the Bazel config described in https://bazel.build/configure/windows#clang with --incompatible_enable_cc_toolchain_resolution.

Which operating system are you running Bazel on?

Windows 10

What is the output of bazel info release?

release 6.1.1

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 master; git rev-parse HEAD ?

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

[e8y]

Also hit this. I manually renamed the directory 'C:/Program Files/LLVM/lib/clang/16 to 'C:/Program Files/LLVM/lib/clang/16.0.0 to get around it for now.

[ohodson]

Also hit this. I manually renamed the directory C:/Program Files/LLVM/lib/clang/16 to C:/Program Files/LLVM/lib/clang/include/16.0.0 to get around it for now.

This is a super helpful suggestion, thank you. This got us a long way when trying to workaround the fallout from github's runner image changes (latest fix actions/runner-images#8125).

We have a project that includes intrinsics and files with intrinsics need a bit more than the suggest. clang-cl.exe uses the include path bazel provides, but also prefixes the include path that it applies with the installed location of headers, e.g. C:/Program Files/LLVM/lib/clang/16. AFAICT, this prefixing is done because the include directory includes headers that have header files with appropriately annotated intrinsics for clang. When that directory is moved, things break because headers in the Windows SDK paths have the same names as the clang intrinsics headers, but different contents. Moving the directory means the (incompatible) Windows headers are picked up and intrinsics aren't desugared into CPU instructions, but left as unresolved functions for the linker to croak on.

Simply copying the include path, instead of moving it, to have an include/16 and include/16.0.X falls foul of the "undeclared inclusion" logic in bazel.

One workaround is to add --per_file_copt entries in .bazelrc to include the clang header path before the INCLUDE path set by bazel. It is very ugly (cloudflare/workerd#1092).

[fmeum]

@bazel-io flag

[iancha1992]

@bazel-io fork 6.4.0

[iancha1992]

A fix for this issue has been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks!

[ohodson]

The project we have using Clang 16 and Bazel, workerd, builds successfully with a clean Clang 16 installation and Bazel 6.4.0 RC1.

Great going, thanks for incorporating the change. Looking forward to dropping the fragile workaround we have in place. 👍🙏