build-std

[nikomatsakis]

Metadata
Point of contact	@davidtwco
Team(s)	cargo, compiler, libs
Goal document	2025h2/build-std

Summary

Over the next six months, we will continue our efforts to write an RFC for a
minimum viable product (MVP) of build-std which has the potential to be
stabilised once implemented (as opposed to the currently implemented MVP which
is only suitable for experimentation and testing), and then implement it.

Tasks and status

• Discussion and moral support (cargo, libs, compiler )
• Author RFC (@davidtwco, @adamgemmell)
• Design meeting (cargo, libs, compiler )
• RFC decision (cargo, libs, compiler )
• Implementation (@davidtwco, @adamgemmell)
• Standard reviews (cargo, libs, compiler )

---

Note: we have updated the body to match the 2025h2 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@davidtwco
Team(s)	cargo
Goal document	2025h1/build-std

Summary

Write an RFC for a minimum viable product (MVP) of build-std which has the potential to be
stabilised once implemented (as opposed to the currently implemented MVP which is only suitable for
experimentation and testing), and then implement it.

Tasks and status

• Discussion and moral support (cargo )
• Author RFC (@adamgemmell)
• Implementation (@adamgemmell)
• Standard reviews (cargo )

[nikomatsakis]

This issue is intended for status updates only.

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

[davidtwco]

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.

[davidtwco]

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

[davidtwco]

• 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.

[wesleywiser]

• @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.

[wesleywiser]

• 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.

[wesleywiser]

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

[adamgemmell]

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.

[nikomatsakis]

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