Move bootstrap configuration to library workspace #149514

adamgemmell · 2025-12-01T17:27:29Z

This creates a new "dist" profile in the standard library which contains configuration for the distributed std artifacts previously contained in bootstrap, in order for a future build-std implementation to use. bootstrap.toml settings continue to override these defaults, as would any RUSTFLAGS provided. I've left some cargo features driven by bootstrap for a future patch.

Unfortunately, profiles aren't expressive enough to express per-target overrides, so this risc-v example was not able to be moved across. This could go in its own profile which Cargo would have to know to use, and then the panic-abort rustflags overrides would need duplicating again. Doesn't seem like a sustainable solution as a couple similar overrides would explode the number of lines here.

We could use a cargo config in the library workspace for this, but this then would have to be respected by Cargo's build-std implementation and I'm not yet sure about the tradeoffs there.

This patch also introduces a build probe to deal with the test crate's stability which is obviously not ideal, I'm open to other solutions here or can back that change out for now if anyone prefers.

cc @Mark-Simulacrum rust-lang/rfcs#3874

This uses a build probe to figure out the current toolchain version - the only alternative to this is bespoke logic in Cargo to tell `test` when the toolchain is stable/unstable. The behaviour should be the same as when using `CFG_DISABLE_UNSTABLE_FEATURES` unless an arbitrary channel is provided to bootstrap, which I believe necessitates a fork anyway.

rustbot · 2025-12-01T17:27:34Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

bjorn3 · 2025-12-02T13:49:33Z

src/bootstrap/src/core/builder/cargo.rs

+            } else {
+                match (mode, self.config.rust_optimize.is_release()) {
+                    // Some std configuration exists in its own profile
+                    (Mode::Std, true) => Some("dist"),


The -Cembed-bitcode=yes has to also be enabled when the standard library is compiled without optimizations. Otherwise the resulting toolchain is unable to do LTO.

bjorn3 · 2025-12-02T13:51:29Z

library/Cargo.toml

+[profile.dist]
+inherits = "release"
+codegen-units = 1
+debug = 1 # "limited"


Doesn't this get unconditionally overridden by the value set for debuginfo-level-std?

Kobzol · 2025-12-13T12:47:05Z

Unfortunately, profiles aren't expressive enough to express per-target overrides, so this risc-v example was not able to be moved across. This could go in its own profile which Cargo would have to know to use, and then the panic-abort rustflags overrides would need duplicating again. Doesn't seem like a sustainable solution as a couple similar overrides would explode the number of lines here.

Doesn't rustc default to -Cforce-unwind-tables=yes since 1.92.0 (https://blog.rust-lang.org/2025/12/11/Rust-1.92.0/#emit-unwind-tables-even-when-cpanic-abort-is-enabled-on-linux)? Or is this not relevant for the standard library? In that case the special case to enable -Cforce-unwind-tables=yes for RISC-V stdlib could be removed. CC @saethlin if you perhaps know.

Kobzol

Left some comments.

In general the changes made so far look relatively minimal and simple. However, currently just moving things to the stdlib's Cargo.toml doesn't change the fact that bootstrap can arbitrarily override them (and likely it does override a bunch of them), in CI dist jobs that can have arbitrary bootstrap configuration enabled.

If we wanted to ensure that this won't happen, we should have some sanity check that will simply deny configuring any cargo overrides and rustflags for the stdlib when we are doing a dist build on CI.

View changes since this review

Kobzol · 2025-12-13T12:48:42Z

src/bootstrap/src/core/builder/cargo.rs

-            // cargo bench/install do not accept `--release` and miri doesn't want it
-            !matches!(cmd_kind, Kind::Bench | Kind::Install | Kind::Miri | Kind::MiriSetup | Kind::MiriTest);
+        let profile =
+            if matches!(cmd_kind, Kind::Bench | Kind::Miri | Kind::MiriSetup | Kind::MiriTest) {


Suggested change

if matches!(cmd_kind, Kind::Bench | Kind::Miri | Kind::MiriSetup | Kind::MiriTest) {

if matches!(cmd_kind, Kind::Bench | Kind::Install | Kind::Miri | Kind::MiriSetup | Kind::MiriTest) {

Previously the code also handled Install, right?

Kobzol · 2025-12-13T12:49:54Z

library/Cargo.toml

+rustflags = [
+    # Unconditionally embedding bitcode is necessary for when users enable LTO.
+    # Until Cargo can rebuild the standard library with the user profile's `lto`
+    # setting, Cargo will force this to be `no`


I don't understand the last sentence here - should that be yes?

Cargo forces -Cembed-bitcode=no when lto = false. The standard library has to be compiled with lto = false to support building user code without LTO, but it has to also use -Cembed-bitcode=yes to support building user code with LTO. Cargo doesn't have a builtin way to express this specific combination of flags.

So in other words, Cargo will pass -Cembed-bitcode=no to locally built stdlib when lto = false, but this rustflags array will still override that to -Cembed-bitcode=yes, right? I just wanted the wording to be clearer, as I didn't understand what it means. "Force this to 'no'" sounds like it overrides the rustflags.

Kobzol · 2025-12-13T12:54:19Z

library/Cargo.toml

 # in the user's profile.
 [profile.dist]
 inherits = "release"
+codegen-units = 1


The cargo_profile_var function will also need to be updated, so that it handles the dist profile (eventually we should make that a hard error, but for now it's some things for Std are configured through it).

Kobzol · 2025-12-13T12:57:21Z

src/bootstrap/src/core/builder/cargo.rs

-        } else {
-            rustflags.arg("-Csymbol-mangling-version=legacy");
-        }
+        rustflags.arg(match use_new_symbol_mangling {


This change should be reverted, to avoid passing an empty flag unnecessarily.

Kobzol · 2025-12-13T12:57:32Z

src/bootstrap/src/core/builder/cargo.rs

+        let use_new_symbol_mangling = self.config.rust_new_symbol_mangling.or_else(|| {
+            if mode != Mode::Std {
+                // The compiler and tools default to the new scheme
+                Some(true)


This lost the logic for the nightly channel.

adamgemmell added 5 commits December 1, 2025 17:14

Move -Cembed-bitcode

ce86629

Move frame pointers

88a5974

Move debuginfo=1

7c01a90

Move symbol mangling

890bbd1

rustbot assigned Mark-Simulacrum Dec 1, 2025

rustbot added A-CI Area: Our Github Actions CI A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 1, 2025

rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 1, 2025

bjorn3 reviewed Dec 2, 2025

View reviewed changes

Kobzol reviewed Dec 13, 2025

View reviewed changes

	if matches!(cmd_kind, Kind::Bench \| Kind::Miri \| Kind::MiriSetup \| Kind::MiriTest) {
	if matches!(cmd_kind, Kind::Bench \| Kind::Install \| Kind::Miri \| Kind::MiriSetup \| Kind::MiriTest) {

Uh oh!

Move bootstrap configuration to library workspace #149514

Are you sure you want to change the base?

Move bootstrap configuration to library workspace #149514

Conversation

adamgemmell commented Dec 1, 2025

Uh oh!

rustbot commented Dec 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kobzol commented Dec 13, 2025

Uh oh!

Kobzol left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Kobzol left a comment •

edited by rustbot

Loading