`./x test library/std` fails with library profile

[clarfonthey]

View all comments

Presumably part of #141901.

Workaround is currently documented in the rustc dev guide.

Command used

./x test library/std

Actual behaviour

Bootstrap configuration (bootstrap.toml)

profile = "library"
change-id = 142379

Operating system

HEAD

9822e3d

Additional context

Build Log (4.5 MiB)

[jieyouxu]

I can't repro with just profile = "library" + ./x test library/std. Does it repro if you remove the build cache and try again?

[clarfonthey]

I had run ./x clean and it still failed, but I'll try git clean too and report back.

[jieyouxu]

Do you have any changes locally?

[clarfonthey]

I did, but I specifically tested on master also in case that affected it. I was working on #142506 and wanted to test that change, which I currently can't do locally because of this.

After doing git clean, I noticed that there was a library/target directory that got removed that might have been created by rust-analyzer and was never removed by ./x clean. I've had a few weird interactions with rust-analyzer in the compiler repo specifically and haven't updated my R-A config to account for it, even though I know there are some suggestions about it.

That said, even after fully wiping out the directory using git clean -xdff and running ./x test library/std, it still seems to have the same issue:

2c2
<     Finished `dev` profile [unoptimized] target(s) in 0.26s
---
>     Finished `dev` profile [unoptimized] target(s) in 0.27s
82093c82093
< Build completed unsuccessfully in 0:00:13
---
> Build completed unsuccessfully in 0:00:14

I do have a custom .cargo/config.toml, but I doubt that is affecting it:

.cargo/config.toml

[registries.crates-io]
protocol = "sparse"

[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"
runner = ["qemu-aarch64-static", "-L", "/usr/aarch64-linux-gnu/"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.aarch64-unknown-linux-musl]
linker = "aarch64-linux-gnu-gcc"
runner = ["qemu-aarch64-static", "-L", "/usr/aarch64-linux-gnu/"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.i686-unknown-linux-gnu]
linker = "gcc"
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.i686-unknown-linux-musl]
linker = "gcc"
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.mips64-unknown-linux-gnuabi64]
linker = "mips64-linux-gnu-gcc"
runner = ["qemu-mips64-static", "-L", "/usr/mips64-linux-gnu/"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.mips64-unknown-linux-muslabi64]
linker = "mips64-linux-gnu-gcc"
runner = ["qemu-mips64-static", "-L", "/usr/mips64-linux-gnu/"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.mips64el-unknown-linux-gnuabi64]
linker = "mips64el-linux-gnu-gcc"
runner = ["qemu-mips64el-static", "-L", "/usr/mips64el-linux-gnu/"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.mips64el-unknown-linux-muslabi64]
linker = "mips64el-linux-gnu-gcc"
runner = ["qemu-mips64el-static", "-L", "/usr/mips64el-linux-gnu/"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.riscv64gc-unknown-linux-gnu]
linker = "riscv64-linux-gnu-gcc"
runner = ["qemu-riscv64-static", "-L", "/usr/riscv64-linux-gnu/"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.x86_64-unknown-linux-gnu]
linker = "gcc"
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.x86_64-unknown-linux-musl]
linker = "gcc"
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.i686-pc-windows-gnu]
linker = "i686-w64-mingw32-gcc"
runner = ["wine"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[target.x86_64-pc-windows-gnu]
linker = "x86_64-w64-mingw32-gcc"
runner = ["wine"]
rustflags = ["-Clink-args=-fuse-ld=mold -B/usr/bin"]

[lolbinarycat]

custom cargo config can definitely have an impact at times, i've broken bootstrap with one before

[clarfonthey]

Yeah, although commenting out this cargo config completely didn't seem to fix anything, as expected.

[clarfonthey]

Gonna try to repro this myself in an Arch Linux container. Will report back with results if I can see what specifically from my setup is causing issues.

Cloning the repo a second time on the same machine did give the same failure results, so, it's definitely some system-wide config.

EDIT: Nope, just running this inside an Arch Linux container with profile = "library" fails for me.

[tgross35]

Fwiw I've been hitting this on MacOS since the bootstrap stage changes. It looks like it's attempting to use an old compiler for some reason; my HEAD is at the latest master e314b97 ("Auto merge of #142550 - fmease:rollup-fteyzcv, r=fmease"), and some of my failures are:

error[E0541]: unknown meta item 'old_name'
   --> library/core/src/ops/control_flow.rs:101:55
    |
101 | #[unstable(feature = "try_trait_v2", issue = "84277", old_name = "try_trait")]
    |                                                       ^^^^^^^^^^^^^^^^^^^^^^ expected one of `feature`, `reason`, `issue`, `soft`, `implied_by`

Which implies b8066f9 ("Tracking the old name of renamed unstable library attribute", merged 06-13) is not in the compiler that std is being built with.

If it helps, bootstrap does the following downloads:

downloading https://static.rust-lang.org/dist/2025-05-26/rust-std-beta-aarch64-apple-darwin.tar.xz
downloading https://static.rust-lang.org/dist/2025-05-26/rustc-beta-aarch64-apple-darwin.tar.xz
downloading https://static.rust-lang.org/dist/2025-05-26/cargo-beta-aarch64-apple-darwin.tar.xz
downloading https://static.rust-lang.org/dist/2025-05-27/rustfmt-nightly-aarch64-apple-darwin.tar.xz
downloading https://static.rust-lang.org/dist/2025-05-27/rustc-nightly-aarch64-apple-darwin.tar.xz
Updating submodule library/stdarch
Submodule 'library/stdarch' (https://github.com/rust-lang/stdarch.git) registered for path 'library/stdarch'
Submodule path 'library/stdarch': checked out '1b4d15df12079504942d0a3f1030b2039b8a776c'
downloading https://ci-artifacts.rust-lang.org/rustc-builds/e314b97ee54091b6bcf33db4770c93d82fded8bc/rust-std-nightly-aarch64-apple-darwin.tar.xz
downloading https://ci-artifacts.rust-lang.org/rustc-builds/e314b97ee54091b6bcf33db4770c93d82fded8bc/rustc-nightly-aarch64-apple-darwin.tar.xz
downloading https://ci-artifacts.rust-lang.org/rustc-builds/e314b97ee54091b6bcf33db4770c93d82fded8bc/rustc-dev-nightly-aarch64-apple-darwin.tar.xz
downloading https://ci-artifacts.rust-lang.org/rustc-builds/ae3b909a323aa771db8ee3919c1454b77db05fbf/rust-dev-nightly-aarch64-apple-darwin.tar.xz
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage0 library artifacts (aarch64-apple-darwin)

My only non-commented bootstrap.toml config:

profile = "library"
change-id = "ignore"

~/.config/cargo.toml ~/.cargo/config.toml (cargo pls support xdg one day) does not exist, and I did rm -rf build target before trying.

And the downloaded stages:

$ build/host/stage1/bin/rustc -V
rustc 1.89.0-nightly (e314b97ee 2025-06-16)
$ build/host/stage0/bin/rustc -V
rustc 1.88.0-beta.4 (95597e848 2025-05-25)

[tgross35]

Printing the bootstrap vvv logs I do see

[RUSTC-SHIM] rustc core env[41]: "RUSTC_STAGE"="0"

Assuming this should be getting set to 1 instead?