Open ernoc opened 1 month ago
Here's a repro for the issue (tested with bazel 7.2.1):
WORKSPACE
:
# Copyright 2024 Google LLC.
# SPDX-License-Identifier: Apache-2.0
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "rules_rust",
integrity = "sha256-35cwdTOaqqu4y+aXgIUU2C2PAKMz4+uyJ7/UMIGCmFs=",
url = "https://github.com/bazelbuild/rules_rust/releases/download/0.47.1/rules_rust-v0.47.1.tar.gz",
)
load("@rules_rust//rust:repositories.bzl", "rules_rust_dependencies", "rust_register_toolchains")
rules_rust_dependencies()
rust_register_toolchains(
edition = "2021",
versions = ["1.78.0"],
extra_target_triples = ["x86_64-unknown-none"],
)
# rust_library requires a C++ toolchain supporting x86_64-unknown-none.
http_archive(
name = "aspect_gcc_toolchain",
sha256 = "3341394b1376fb96a87ac3ca01c582f7f18e7dc5e16e8cf40880a31dd7ac0e1e",
strip_prefix = "gcc-toolchain-0.4.2",
url = "https://github.com/aspect-build/gcc-toolchain/archive/refs/tags/0.4.2.tar.gz",
)
load("@aspect_gcc_toolchain//toolchain:repositories.bzl", "gcc_toolchain_dependencies")
gcc_toolchain_dependencies()
load("@aspect_gcc_toolchain//toolchain:defs.bzl", "ARCHS", "gcc_register_toolchain")
gcc_register_toolchain(
name = "gcc_toolchain_x86_64_unknown_none",
extra_ldflags = ["-nostdlib"],
target_arch = ARCHS.x86_64,
target_compatible_with = ["@platforms//cpu:x86_64", "@platforms//os:none"],
)
load("@rules_rust//crate_universe:defs.bzl", "crate", "crates_repository")
# anyhow builds: bazel build --platforms=//:x86_64-unknown-none --@rules_rust//:no_std=alloc @anyhow_crate_index//:anyhow
crates_repository(
name = "anyhow_crate_index",
cargo_lockfile = "//:anyhow.lock",
lockfile = "//:anyhow-lock.json",
packages = {
"anyhow": crate.spec(default_features = False, version = "1.0"),
},
rust_version = "1.78.0",
supported_platform_triples = ["x86_64-unknown-linux-gnu", "x86_64-unknown-none"],
)
load("@anyhow_crate_index//:defs.bzl", anyhow_crate_repositories = "crate_repositories")
anyhow_crate_repositories()
# prost-types builds: bazel build --platforms=//:x86_64-unknown-none --@rules_rust//:no_std=alloc @broken_crate_index//:prost-types
# anyhow now fails to build: bazel build --platforms=//:x86_64-unknown-none --@rules_rust//:no_std=alloc @broken_crate_index//:anyhow
crates_repository(
name = "broken_crate_index",
cargo_lockfile = "//:broken.lock",
lockfile = "//:broken-lock.json",
packages = {
"anyhow": crate.spec(default_features = False, version = "1.0"),
"prost-types": crate.spec(default_features = False, version = "0.12"),
},
rust_version = "1.78.0",
supported_platform_triples = ["x86_64-unknown-linux-gnu", "x86_64-unknown-none"],
)
load("@broken_crate_index//:defs.bzl", broken_crate_repositories = "crate_repositories")
broken_crate_repositories()
BUILD
:
# Copyright 2024 Google LLC.
# SPDX-License-Identifier: Apache-2.0
platform(
name = "x86_64-unknown-none",
constraint_values = [
"@platforms//cpu:x86_64",
"@platforms//os:none",
],
)
Repro steps:
$ touch {anyhow,broken}{.lock,-lock.json} && CARGO_BAZEL_REPIN=1 bazel sync
$ bazel build --platforms=//:x86_64-unknown-none --@rules_rust//:no_std=alloc @anyhow_crate_index//:anyhow @broken_crate_index//:prost-types # succeeds
$ bazel build --platforms=//:x86_64-unknown-none --@rules_rust//:no_std=alloc @broken_crate_index//:anyhow # fails
...
error[E0463]: can't find crate for `std`
--> external/broken_crate_index__anyhow-1.0.86/src/lib.rs:251:1
|
251 | extern crate std;
| ^^^^^^^^^^^^^^^^^ can't find crate
|
= note: the `x86_64-unknown-none` target may not support the standard library
prost-types
depends on prost-derive
, which is a proc macro (i.e. provides compile-time codegen rules). prost-derive
depends on anyhow
with the std
feature -- which is okay because the usage only happens at compile time. But crates_repository
merges features across all dependencies -- including those reached via proc macros -- resulting in the std
feature being added to @broken_crate_index//:anyhow
(compare the anyhow
entries in anyhow-lock.json
and broken-lock.json
).
This is similar to https://github.com/bazelbuild/rules_rust/issues/205, but in addition to building proc macros for the host platform, I believe dependencies of proc macros (or at least their features) also need to be isolated between the host and target platforms.
Given:
prost-types
)rules_rust will pull in the proc macro's dependencies and then propagate the
std
feature to all crates in the index, meaning no we can no longer build our crate for bare metal.