Add `--dist-std` bootstrap flag - #158264

adamgemmell · 2026-06-22T17:01:04Z

The configuration used by std needs to be moved to somewhere the new build-std can see it. This PR moves settings that Cargo can model in its profile to the dist profile and ensures that bootstrap does not try to override them.

This PR adds a new Mode, DistStd, to bootstrap, as proposed by @Kobzol a while ago, which is used when building the standard library and when passing the --dist-std flag to certain bootstrap commands. This new mode:

Uses the dist profile in the library workspace, added in Move bootstrap configuration to library workspace #149514
- Normal builds revert back to using release/dev, which fixes building std without optimisations
Disallows overriding any profile fields. Configuration in dist builds that do this should instead place the configuration in the library workspace so that it can also be used by build-std.

The PR also moves some rustflags that are unconditionally passed when building std over to the library workspace.

Planned followups for this work:

Allow -Zbuild-std to consume standard library config files which will allow for configuring the standard library much more flexibly
Move CI jobs over to using --dist-std, which involves moving all configuration from the jobs (and CI scripts like run.sh) over to the library workspace or configuration.
Add more sanity checks to bootstrap to ensure that standard library configuration is not overridden when --dist-std is passed.
Simplify the dev/release profiles after that, which can now be tailored exclusively for local builds by contributors.

🤖 LLM disclosure: I used Codex primarily to explain certain concepts in bootstrap to me and asked it to review my branch before sharing it upstream. There is no LLM-generated content in the branch or PR itself.

rustbot · 2026-06-22T17:01:10Z

r? @clubby789

rustbot has assigned @clubby789.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: bootstrap
bootstrap expanded to 6 candidates
Random selection from Mark-Simulacrum, clubby789, jieyouxu

adamgemmell · 2026-06-22T17:01:32Z

r? @Kobzol

rustbot · 2026-06-22T17:01:38Z

kobzol is not on the review rotation at the moment.
They may take a while to respond.

bjorn3 · 2026-06-22T20:24:39Z

+    # That causes some mir-opt tests which inline functions from the standard library to
+    # break when incremental compilation is enabled. So this overrides the "no inlining
+    # during incremental builds" heuristic for the standard library.
+    "-Zunstable-options",


What is this necessary for? None of the other rustflags are both unstable and not behind -Z, so -Zunstable-options shouldn't be necessary afaict.

View changes since the review

Cargo does pass it unconditionally here, though I didn't disable it doing so in this commit. It's not necessary for the dist profile I agree, but might still be for some certain configs for other builds

Ended up reverting this change as -Cforce-frame-pointers=non-leaf requires -Zunstable options

bjorn3 · 2026-06-22T20:36:38Z

What is the motivation for this? This would make it harder for distros to change how the standard library gets built, right? For example a distro might want to enforce overflow checks for the standard library for security reasons. Or they might want to disable LTO because the codegen backend they chose doesn't support LTO. Or they might want to build the standard library with full debuginfo. I also personally have used ./x.py dist a couple of times to get a standalone toolchain for testing with the expectation that it is just a superset of what ./x.py build produces. Some config options suddenly getting ignored or suddenly getting a panic because I didn't restore some config options to the default would be annoying.

adamgemmell · 2026-06-23T10:21:14Z

The motivation is enforcing that any configuration for dist builds lives somewhere that build-std can see it. We had some discussion on zulip a while ago: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Standard.20library.20dist.20configuration. From that the two main complications that led to this approach were:

Bootstrap unconditionally sets some configuration based on bootstrap.toml defaults, like rust.debuginfo-level-std (which inherits from rust.debug). We'd like to avoid duplication where possible to avoid divergence - perhaps std configuration should defer to what's in the standard library profile by default.

Dist jobs may set configuration via ./configure which masks what's in the library workspace. Some kind of sanity check would be nice here, which is certainly doable in this function for profile vars (though @jakub Beránek recommended against this unless necessary). Arbitrary RUSTFLAGS are harder, but I think over time we can get to a spot where codegen configuration is in the profile or even .cargo/config other than RUSTFLAGS.

The intention is that panic never triggers, it's a sanity check for bootstrap itself.

Yes, this is quite disruptive and annoying, and anyone doing dist builds would need to translate all their options to the library manifest, but distros need to do this anyway so the build-std artifacts have the same compatibility as the prebuilt std.

I'm not sure on the best way to make this less disruptive - perhaps it should only ignore config options when DEPLOY=1, and should at least print a warning.

bjorn3 · 2026-06-23T10:30:54Z

but distros need to do this anyway so the build-std artifacts have the same compatibility as the prebuilt std.

For example for the debuginfo options, if a distro wants to enable full debuginfo for their precompiled standard library, they probably don't want to enable full debuginfo for end users that use -Zbuild-std. Several of the options the precompiled standard library is compiled with are just to because of the fact that users on stable can't use -Zbuild-std to enable them if they need them. They don't make sense to enforce for -Zbuild-std.

adamgemmell · 2026-06-23T10:34:09Z

The initial version of build-std we're stabilising doesn't support customising the standard library, it should match the distributed std as closely as possible. When we change Cargo to use the dist profile, we'll add an unstable option that keeps the "user profile" behaviour build-std currently has.

bjorn3 · 2026-06-23T10:38:57Z

You are adding several of these flags even to the non-dist profiles.

adamgemmell · 2026-06-23T10:46:49Z

I've only moved over options that are unconditionally passed by bootstrap. This is because I'd like to explore doing something similar to RUSTFLAGS as I have for profile variables here, but I'm happy to defer that.

bjorn3 · 2026-06-23T10:52:34Z

The -Cembed-bitcode=yes is only applicable to the precompiled standard library as it has to work with both LTO and non-LTO builds. For cargo built standard library the appropriate value already passed automatically and -Cembed-bitcode=yes for a non-LTO build would only increase the target dir size. And -Zinline-mir is also probably only necessary for ./x.py build when incr comp is enabled, though that one would just be a no-op for -Zbuild-std and is thus fine to keep.

adamgemmell · 2026-06-23T11:06:15Z

LTO is off for the standard library's own profile. Presumably if it were on then LTO would run twice for it if the user requested it too?

bjorn3 · 2026-06-23T11:12:15Z

-Cembed-bitcode=yes allows a crate to be used as dependency of a crate that is LTOed. Cargo will always enable this when LTO is enabled and will always pass -Cembed-bitcode=no when LTO is disabled. The precompiled standard library needs to be compiled with -Cembed-bitcode=yes even though it isn't actually getting LTOed to ensure users can enable LTO without needing to recompile the standard library. With -Zbuild-std, -Cembed-bitcode already gets to true by cargo iff the user requested LTO due to the standard library just being another dependency. No need to force -Cembed-bitcode=yes when the user didn't request LTO.

adamgemmell · 2026-06-23T11:18:22Z

It won't be with build-std's currently approved RFCs, as until we introduce build-std=match-profile cargo won't look at the user's profile when configuring std.

adamgemmell · 2026-06-23T14:24:29Z

@bors retry

rust-bors · 2026-06-23T14:24:32Z

❗ You can only retry pull requests that are approved and have a previously failed auto build.

bjorn3 · 2026-06-23T14:32:03Z

I've retried the PR CI from the github interface for you. Bors is not involved with PR CI, only try runs and pre-merge CI.

adamgemmell · 2026-06-30T14:26:04Z

        // Some std configuration exists in its own profile
-        (Mode::Std, _) => "DIST",
+        (Mode::DistStd, _) => {
+            panic!("Attempted to override the distributed std's profile with {name}")


Capturing bjorn's message here in a comment, namely that we're still working out if this is the right approach for distros and contributors who use x.py dist

View changes since the review

View changes since the review

Kobzol · 2026-06-30T18:36:52Z

Hmm, hmm... This is tricky.

Gating whether we choose Std or DistStd based on x build vs x dist is not great. It should be possible to run x dist to produce an arbitrary std that you want, it's only specifically our CI dist jobs that should produce stdlib that will be as close as possible to build-std, not all disted stdlib artifacts.

This might also introduce more differences between stdlib that we test on CI and stdlib that we dist. There are already differences there caused by various CI config options, but now it would also exercise different paths in bootstrap, which doesn't seem good to me.

There are various approaches at making this work; bjorn's rustc-build-sysroot executable, using -Zbuild-std directly in bootstrap, and having some notion of bootstrap sanity checks. Ideally we'd write down our end goals and compare those approaches to enumerate their trade-offs - a very "pleasant" activity, I know 😆 I'll take a look.

adamgemmell · 2026-07-01T11:01:45Z

@Kobzol I asked Fabian here and came the same conclusion on bootstrap subcommands. I considered gating the behaviour on DEPLOY but at least debian doesn't seem to set that - I'm not sure if it's intended for external users or that it's just useful for rust's CI. Probably a flag would be better.

It's not clear to me how a rustc-build-sysroot layer could help or change much here. It could take responsibility for configuring the DistStd away from the library profile, but while tidier and more flexible that doesn't seem functionally better.

I don't understand the motivation behind bootstrap using build-std either, given what the flag does in Cargo is basically a bunch of hacks and tricks to pretend that you've added std as dependencies of your crates and dependencies and make it as normal as possible when the building actually happens. If std is the current crate you don't need to do anything like that as there isn't much special once you're actually building std, unless we decided to adopt rustc-build-sysroot of course.

rustbot · 2026-09-14T15:58:10Z

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

rustbot · 2026-09-14T16:00:35Z

Some changes occurred in src/tools/cargo

cc @weihanglo

rustbot · 2026-09-14T16:00:38Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

DistStd uses the dist profile for the standard library while Std uses debug/release, but otherwise these two are the same in this commit.

As a previous commit changes CI to use the dev/release profiles by default we need to move the dist profile settings there for now.

This commit adds a panic when attempting to override the dist profile of the standard library. This means that the standard library will no longer respect some bootstrap settings when built with `--dist-std`, instead forcing them to be set in the dist profile of the standard library.

adamgemmell · 2026-09-14T16:06:25Z

I've reworked this PR significantly to tighten its scope. The Mode::DistStd behaviour is now behind a --dist-std flag as discussed. CI jobs do not yet use Mode::DistStd and so go back to using debug/release profiles. This means some configuration that has already been moved to the dist profile has been copied to those profiles. See the updated PR description for more context

@weihanglo sorry for the noise, no cargo changes are intended in this

adamgemmell requested a review from Kobzol June 22, 2026 17:01

rustbot assigned clubby789 Jun 22, 2026

rustbot assigned Kobzol and unassigned clubby789 Jun 22, 2026

bjorn3 reviewed Jun 22, 2026

View reviewed changes

Comment thread library/Cargo.toml Outdated

bjorn3 reviewed Jun 22, 2026

View reviewed changes

Comment thread library/Cargo.toml

bjorn3 reviewed Jun 22, 2026

View reviewed changes

Comment thread library/Cargo.toml Outdated

bjorn3 reviewed Jun 22, 2026

View reviewed changes

Comment thread src/bootstrap/src/core/builder/cargo.rs Outdated