build-std

@adamgemmell

Metadata
Contact	@adamgemmell
Team(s)	cargo (@ehuss), compiler, crates-io, libs
Goal document	2026/build-std
Funding contact	Funding team

Summary

Complete the remaining design work for #3874 and #3875 and start on implementation.

This issue is intended for status updates only.

For general questions or comments, please contact a goal owner or post in the Zulip topic.

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

@adamgemmell

An initial update on what we've been up to and some background:

This goal is submitted on behalf of the Rust team at Arm, but primarily worked on by @adamgemmell. Anyone interested can always contact me for updates and I'll keep this issue up-to-date.
Our team has been trying to make progress on build-std by completing the issues in rust-lang/wg-cargo-std-aware but found this wasn't especially effective as there wasn't a clearly defined scope or desired outcome for most issues and the relevant teams were lacking in the necessary context to evaluate any proposals.
We've since had discussions with the Cargo team and agreed to draft a document describing the use cases, motivations and prior art for build-std such that the Cargo team can feel confident in reviewing any further proposals.
- @adamgemmell shared an initial draft of this in #t-cargo on Zulip and it is undergoing further revisions following feedback.
- Following reaching a shared understanding of the context of the feature, @adamgemmell will then draft a complete proposal for build-std that could feasibly be stabilised. It will describe the use cases which are and are not considered in-scope for build-std, and which will feature in an initial implementation.
@davidtwco is ensuring that whatever mechanism that is eventually proposed to enable build-std to work on stable toolchains will also be suitable for the Rust for Linux project to use when building core themselves.

@adamgemmell

A small update, @adamgemmell shared revisions to the aforementioned document, further feedback to which is being addressed.

@adamgemmell

We've started a regular biweekly sync call with upstream stakeholders in build-std from the lang, compiler and cargo teams where we discuss aspects of our tentative design or clarify constraints.
@adamgemmell has continued to draft our proposal for build-std, which we're discussing in our regular sync calls.
We're hosting a session at the All Hands next week to discuss build-std.

@adamgemmell

@adamgemmell and @davidtwco hosted a session on build-std at the All Hands with members from various teams discussing some of the design questions.
We've continued our biweekly sync call with lang, compiler and cargo team members.
@davidtwco and @adamgemmell have been hard at work preparing a compendium detailing the history of build-std and the wg-cargo-std-aware repo.
- Reviewing and editing this document is ongoing and a continuing topic of discussion for the sync call.
In the last sync call, we discussed:
- Renewing the project goal for another cycle: enthusiastic agreement from many participants.
- Posting updates to the project goal page biweekly after each sync call.
- Discussion on the content and format of the compendium. Most of the content appears to be done but further editing and restructuring will make it clearer and more easily digestible.

@davidtwco

Updates from our biweekly sync call:
- Discussed the latest round of feedback on the pre-RFC, the most significant of which is that the scope of the RFC is almost certainly too large for an MVP.
- @davidtwco presented a reformulation of the plan which focuses on the core components of build-std and leaves more features for future extensions after a minimal MVP:
  - Stage 1a: Introduce manual controls for enabling the build-std behavior in Cargo.
  - Stage 1b: Introduce Cargo syntax to declare explicit dependencies on core, alloc and std crates.
    - This stage enables the use of Tier 3 targets on stable Rust and allows the ecosystem to start transitioning to explicit dependencies on the standard library.
    - This stage would be considered the minimal MVP.
  - Stage 2: Teach Cargo to build std with different codegen/target modifier options.
    - This stage allows the standard library to be compiled with custom codegen options.
  - Stage 3: Enable automatic standard library rebuilds.
    - This stage focuses on making build-std behave ergonomically and naturally without users having to manually ask for the standard library to be built.
- General consensus was reached that this plan feels viable. @davidtwco will write the Stage 1a/b RFC.
- Some discussion on various threads from the previous RFC draft.

Continuing the build-std work has been submitted as a Project Goal for 2025H2: https://rust-lang.github.io/rust-project-goals/2025h2/build-std.html

Recently we've been working on feedback on the multi-staged format of the RFC. We've also shared the RFC outside of our sync call group to people from a variety of project teams and potential users too.

We're now receiving feedback that is much more detail-oriented, as opposed to being about the direction and scope of the RFC, which is a good indication that the overall strategy for shipping this RFC seems promising. We're continuing to address feedback to ensure the RFC is clear, consistent and technically feasible. David's feeling is that we've probably got another couple rounds of feedback from currently involved people and then we'll invite more people from various groups before publishing parts of the RFC formally.

This is a continuing project goal, and the updates below this comment will be for the new period 2025h2

This is a continuing project goal, and the updates below this comment will be for the new period 2026

Since our last update, we've been working on rust-lang/cargo#16675, which is now feature-complete pending a refactor and reviews, and a patch for bootstrap that prevents the configuration in the dist profile from being overridden. We've discussed and are exploring alternative implementation approaches such as a rustc-build-sysroot tool shipped with rustc that would build the standard library, but there are still open questions about this approach and we've not committed to going with it. A big risk for this goal is that the Cargo team no longer has sufficient bandwidth to provide reviews - we're trying to source addl. funding for that team to keep this goal going but that is very speculative.

@adamgemmell

Since our last update, we've been pushing forward on a handful of the build-std parts that seem trickier and have open questions:

In Move bootstrap configuration to library workspace rust#149514, @adamgemmell moved the standard library's configuration out of bootstrap into the a new dist profile that build-std would be able to use
- Add --dist-std bootstrap flag rust#158264 follows up on that to prevent dist jobs from overriding the dist profile
Assume the effects of RUSTC_BOOTSTRAP in sysroot rust#151684 is open to assume RUSTC_BOOTSTRAP when compilation is in the sysroot, it's waiting until the build-std implementation is more advanced
We have an implementation of the --no-implicit-sysroot-deps that we'll upstream when the Cargo implementation is more advanced
Build-std: Add builtin dependencies cargo#16675 is functionally ready but @adamgemmell plans to revisit and do a refactoring so the PR is structured in the way that t-cargo prefer
@bjorn3 landed Include vendored sources in the rust-src component rust#156196 putting vendored sources in rust-src and @adamgemmell is working on a patch for Cargo that will enable it to leverage this (that patch enables standard library builds to have their own configuration within Cargo that could point towards the patched sources)
@Bryanskiy opened Build-std: panic strategies cargo#17185 to support different panic strategies with build-std
@npmccallum opened a patch supporting build-std with artifact dependencies in fix(build-std): include artifact dependency targets cargo#17074

Cargo is still struggling with review capacity, and I'm doing what I can to try and find funding to keep this work moving. @ehuss has let us know that he won't be able to continue to be our champion for this goal - we thank him for all of his help in getting this far, and I'll work on finding a new champion from the Cargo team.

@adamgemmell

We've been focused on implementation work since our last update, but are still limited by the reviewing capacity in Cargo at the moment.

@adamgemmell has continued working on Build-std: Add builtin dependencies cargo#16675 going through multiple rounds of feedback primarily around reducing the burden on reviewers. I've also landed (and sometimes reverted) a series of refactor PRs supporting this PR. Currently it's split into a series of smaller PRs introducing concepts which will be exercised by a later patch that moves -Zbuild-std to using them:
@adamgemmell has landed Add -Zimplicit-sysroot-deps rust#159717, originally by @CrooseGit, which allows the disabling of looking for direct dependencies in the sysroot, requiring them to be explicitly passed in via --extern. A future patch will enable this in Cargo to prevent "duplicate lang item" errors with -Zbuild-std.
@Bryanskiy has landed allow -Ldependency search paths for panic runtimes rust#160007 which allows rustc to load injected dependencies (panic runtimes & compiler_buitlins) from -Ldependency= paths, which unblocks Build-std: panic strategies cargo#17185

We've been making steady progress upstreaming work moving to the new "opaque dependencies" design in Cargo.

Work has started on Tracking Issue for build-std explicit dependencies cargo#16960 (comment) in order to unblock parts of this, and the tracking issue is now much more detailed.
- Merged most of the Cargo manifest changes required for builtin deps: feat(builtin-deps): Add unstable builtin-dependencies feature cargo#17497, feat(builtin-deps): Add builtin dependencies manifest syntax cargo#17498, fix(builtin-deps): Builtin dependencies manifest validation cargo#17499, test(builtin-deps): Additional manifest regression tests cargo#17500
- Merged an internal representation for builtin sources: feat(builtin-deps): Add SourceKind::Builtin cargo#17513
- Merged package ID spec parsing and formatting for builtin packages: feat(pkgid-spec): Builtin package spec parsing and formatting cargo#17539

The way forward will likely involve introducing the new build-std UI and getting that working end-to-end before eventually removing the existing -Zbuild-std flag.

Navigation Menu

Repository navigation

build-std #274

Summary

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

build-std #274

Description

Summary

Activity

nikomatsakis commented on Feb 18, 2025

davidtwco commented on Feb 19, 2025

davidtwco commented on Mar 3, 2025

davidtwco commented on May 7, 2025

wesleywiser commented on Jun 19, 2025

wesleywiser commented on Jul 22, 2025

wesleywiser commented on Jul 28, 2025

adamgemmell commented on Sep 12, 2025

nikomatsakis commented on Sep 16, 2025

nikomatsakis commented on Sep 16, 2025

nikomatsakis commented on Sep 16, 2025

22 remaining items

tomassedovic commented on May 5, 2026

davidtwco commented on Jun 16, 2026

davidtwco commented on Jul 15, 2026

adamgemmell commented on Sep 3, 2026

adamgemmell commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions