bazelbuild / bazelbuild/bazel

Absolute path inclusion validation breaks C++26's `#embed` on Clang / macOS

Open
#26,150 17 comments 0 reactions 0 assignees View on GitHub
P3 team-Rules-CPP type: bug
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 18h
Merged PRs (30d)
75

Description

### Description of the bug:

Clang ships the C++26 [resource inclusion using `#embed`](https://en.cppreference.com/w/cpp/preprocessor/embed) since version 19. This feature allows to include raw binary content directly into the compilation output. While the standard just says that the name given to the `#embed` directive is used in an "implementation defined" way to lookup the resource, in clang, it effectively is a path relative to the source file. Yet, bazel fails the build, claiming that a file was included by an absolute path:
```
ERROR: /.../embed-issue-project/BUILD.bazel:1:8: Compiling embed-issue.cpp failed: absolute path inclusion(s) found in rule '//:embed-issue':
the source file 'embed-issue.cpp' includes the following non-builtin files with absolute paths (if these are builtin files, make sure these paths are in your toolchain):
'/.../embed-issue-project/embed-issue.dat'
```

### 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.

Prepare the following project files:

**`MODULE.bazel`**
```bazel
module(
name = "embed-issue",
version = "0.1.0",
)

bazel_dep(name = "rules_cc", version = "0.0.17")
bazel_dep(name = "toolchains_llvm", version="1.4.0")
llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm")
llvm.toolchain(
cxx_standard = {"": "c++2c"},
llvm_version = "20.1.2",
)
use_repo(llvm, "llvm_toolchain")
register_toolchains("@llvm_toolchain//:all")
```

**`BUILD.bazel`**
```bazel
cc_test(
name = "embed-issue",
srcs = [
"embed-issue.cpp",
],
data =[
"embed-issue.dat",
],
)
```

**`embed-issue.cpp`**
```c++
#include

static const unsigned char data[] = {
#embed "embed-issue.dat"
};

int main() {
std::println("Embedded data: {}",data);
return 0;
}
```

**`embed-issue.dat`**
```
hello-world
```

Then, run
```bash
bazel test :embed-issue
```

### Which operating system are you running Bazel on?

macOS

### What is the output of `bazel info release`?

release 8.2.0-homebrew

### 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` ?

```text

```

### 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?

Searching neither StackOverflow nor previous issues on GitHub turned up anything that seems to relate to `#embed`.

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

_No response_

Contributor guide

Open the contributing guide

Research direction

Reproduce the failure with MODULE.bazel, BUILD.bazel, embed-issue.cpp, and embed-issue.dat using `bazel test :embed-issue`. Start by tracing the C++ rules' absolute-path inclusion validation for Clang's `#embed` handling. Done means the minimal macOS project builds and tests without rejecting the embedded data file as an absolute inclusion, with coverage for this case.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.