rust-1.90.0 prerelease tries to download rust-std in offline mode

[stefson]

hey everyone,

I've just downloaded the rust-1.90.0 prerelease tarball, and tried to compile it. It didn't work, because something tries to download a rust-std:

>>> Compiling source in /var/tmp/portage/dev-lang/rust-1.90.0/work/rustc-1.90.0-src ...
downloading https://static.rust-lang.org/dist/2025-08-07/rust-std-1.89.0-x86_64-unknown-linux-gnu.tar.xz
running: curl --progress-bar --retry-all-errors --location --speed-time 30 --speed-limit 10 --connect-timeout 30 --output /var/tmp/portage/dev-lang/rust-1.90.0/temp/tmp1ribmlnu --continue-at - --retry 3 --show-error --remote-time --fail https://static.rust-lang.org/dist/2025-08-07/rust-std-1.89.0-x86_64-unknown-linux-gnu.tar.xz
curl: (6) Could not resolve host: static.rust-lang.org
Warning: Problem : timeout. Will retry in 1 second. 3 retries left.

this can't work, because I'm building in a sandbox via emerge*, which doesn't allow any online fetching of external sources. (emerge is gentoo's package manager)

this command is used:

RUST_BACKTRACE=1 python3.13 ./x.py build -vvv --config=/var/tmp/portage/dev-lang/rust-1.90.0/work/rustc-1.90.0-src/bootstrap.toml -j12

[llvm]
llvm.download-ci-llvm = false
llvm.optimize = true
llvm.release-debuginfo = false
llvm.assertions = false
llvm.ninja = true
llvm.targets = "AArch64;X86;ARM;WebAssembly"
llvm.experimental-targets = ""
llvm.link-shared = false


llvm.enable-warnings = false
[llvm.build-config]
CMAKE_VERBOSE_MAKEFILE = "ON"
CMAKE_C_FLAGS_RELEASE = "-O2 -march=znver1 -pipe"
CMAKE_CXX_FLAGS_RELEASE = "-O2 -march=znver1 -pipe"
CMAKE_EXE_LINKER_FLAGS_RELEASE = "-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs"
CMAKE_MODULE_LINKER_FLAGS_RELEASE = "-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs"
CMAKE_SHARED_LINKER_FLAGS_RELEASE = "-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs"
CMAKE_STATIC_LINKER_FLAGS_RELEASE = ""
[build]
build.build-stage = 2
build.test-stage = 2
build.build = "x86_64-unknown-linux-gnu"
build.host = ["x86_64-unknown-linux-gnu"]
build.target = ["x86_64-unknown-linux-gnu"]
build.cargo = "/var/tmp/portage/dev-lang/rust-1.90.0/work/rust-stage0/bin/cargo"
build.rustc = "/var/tmp/portage/dev-lang/rust-1.90.0/work/rust-stage0/bin/rustc"
build.rustfmt = "/var/tmp/portage/dev-lang/rust-1.90.0/work/rust-stage0/bin/rustfmt"
build.docs = false
build.compiler-docs = false
build.submodules = false
build.python = "python3.13"
build.locked-deps = true
build.vendor = true
build.extended = true
build.tools = ["cargo","rustdoc","rustfmt"]
build.verbose = 2
build.sanitizers = false
build.profiler = true
build.cargo-native-static = false
[install]
install.prefix = "/usr/lib/rust/1.90.0"
install.sysconfdir = "etc"
install.docdir = "share/doc/rust"
install.bindir = "bin"
install.libdir = "lib"
install.mandir = "share/man"
[rust]
# https://github.com/rust-lang/rust/issues/54872
rust.codegen-units-std = 1
rust.optimize = true
rust.debug = false
rust.debug-assertions = false
rust.debug-assertions-std = false
rust.debuginfo-level = 0
rust.debuginfo-level-rustc = 0
rust.debuginfo-level-std = 0
rust.debuginfo-level-tools = 0
rust.debuginfo-level-tests = 0
rust.backtrace = true
rust.incremental = false
rust.default-linker = "x86_64-pc-linux-gnu-gcc"
rust.channel = "stable"
build.description = "gentoo"
rust.rpath = false
rust.verbose-tests = true
rust.optimize-tests = true
rust.codegen-tests = true
rust.dist-src = false
rust.remap-debuginfo = true
rust.lld = false
# only deny warnings if doc+wasm are NOT requested, documenting stage0 wasm std fails without it
# https://github.com/rust-lang/rust/issues/74976
# https://github.com/rust-lang/rust/issues/76526
rust.deny-warnings = true
rust.backtrace-on-ice = true
rust.jemalloc = false
# See https://github.com/rust-lang/rust/issues/121124
rust.lto = "off"
[dist]
dist.src-tarball = false
dist.compression-formats = ["xz"]
dist.compression-profile = "balanced"
[target.x86_64-unknown-linux-gnu]
ar = "x86_64-pc-linux-gnu-ar"
cc = "x86_64-pc-linux-gnu-gcc"
cxx = "x86_64-pc-linux-gnu-g++"
linker = "x86_64-pc-linux-gnu-gcc"
ranlib = "x86_64-pc-linux-gnu-ranlib"
rust.llvm-libunwind = "no"

my OS is gentoo linux 64bit

the git-commit-hash is 1159e78

[Mark-Simulacrum]

The config parsing in bootstrap.py doesn't seem to read build.rustc/build.cargo = "...". If you adjust the config to have those in the [build] section then rust-std isn't downloaded AFAICT.

I'm not sure if this is a regression or not but since the workaround is simple I doubt we'll rebuild stable artifacts at this point. Can you check if the ~same config shape worked in previous releases? I'm not seeing anything recent that looks like it might have broken that.

[Kobzol]

The TOML config should be either

[build]
cargo = "..."

or

build.cargo = "..."

but not both. How did you generate/create the bootstrap.toml file?

[stefson]

The toml config file I used was recycled from rust-1.89.0, and the first error I encountered was about description = "gentoo" not found by bootstrap. I diffed the bootstrap.example file shipped with 1.89.0 and 1.90.0, and learned about the new way to add llvm. or rust. in front of every value. So I changed it for the whole toml config file, and this is how I ended with the above error.

I just started all over with the old config, and only moved description ="gentoo" up into the build category, and this fixed the initial error about description not being found. I'm not sure if the above toml config file is my error, or if that is a real bug.

[Kobzol]

It's not really a new way of bootstrap doing something, that's how TOML works - you can specify things either as [table] key = "value" or as table.key = "value". We just use the second format in the example TOML now.

CC @lolbinarycat An example of a real-world confusion caused by the new config format :) (but I still think it was worth it to change it)

[lolbinarycat]

It seems to me part of the issue is that if bootstrap.py encounters an error in bootstrap.toml, it doesn't even print a warning, just silently ignores it.

I think one thing we could do to help with this type of error is produce a helpful diagnostic when a key is in the wrong section or overly nested, although that would probably require some advanced serde magic (I'll see what I can do).

[lolbinarycat]

Ok, so bootstrap is using a very old version of toml, (0.5.x, newest is 0.9.x), and thus has very limited ability to access structured details of toml::de::Error. we could either do string processing of the error message (unreliable), or get toml to expose toml::de::ErrorKind so we can pattern match on that. From my limited local testing updating toml to a new version should be fairly trivial.

[Kobzol]

Usually the concern for bootstrap is dependency count, I think that the newer toml has more deps?

We could try to parse something like rust: Option<Box<Self>> and if it succeeds, then provide an error message. I'm not sure if it's worth it though.