Project goals

This repo tracks the effort to set and track goals for the Rust project.

Next goal period (2026)

The next goal period will be 2026. We are currently in the process of assembling goals. Click here to see the current list. If you’d like to propose a goal, instructions can be found here.

Current goal period (2025H2)

The 2025H2 goal period runs from Sept 1 to Dec 31. We have identified 12 flagship goals, broken out into four themes:

• Beyond the &, making it possible to create user-defined smart pointers that are as ergonomic as Rust’s built-in references &.
• Unblocking dormant traits, extending the core capabilities of Rust’s trait system to unblock long-desired features for language interop, lending iteration, and more.
• Flexible, fast(er) compilation, making it faster to build Rust programs and improving support for specialized build scenarios like embedded usage and sanitizers.
• Higher-level Rust, making higher-level usage patterns in Rust easier.

“Beyond the &”

One of Rust’s core value propositions is that it’s a “library-based language”—libraries can build abstractions that feel built-in to the language even when they’re not. Smart pointer types like Rc and Arc are prime examples, implemented purely in the standard library yet feeling like native language features. However, Rust’s built-in reference types (&T and &mut T) have special capabilities that user-defined smart pointers cannot replicate. This creates a “second-class citizen” problem where custom pointer types can’t provide the same ergonomic experience as built-in references.

The “Beyond the &” initiative aims to share &’s special capabilities, allowing library authors to create smart pointers that are truly indistinguishable from built-in references in terms of syntax and ergonomics. This will enable more ergonomic smart pointers for use in cross-language interop (e.g., references to objects in other languages like C++ or Python) and for low-level projects like Rust for Linux which use smart pointers to express particular data structures.

“Unblocking dormant traits”

Rust’s trait system is one of its most powerful features, but it has a number of longstanding limitations that are preventing us from adopting new patterns. The goals in this category unblock a number of new capabilities:

• Polonius will enable new borrowing patterns, and in particular unblock “lending iterators”. Over the last few goal periods we have identified an “alpha” version of polonius that addresses the most important cases while being relatively simple and optimizable. Our goal for 2025H2 is to implement this algorithm in a form that is ready for stabilization in 2026.
• The next gen trait solver is a refactored trait solver that unblocks better support for numerous language features (implied bounds, negative impls, the list goes on) in addition to closing a number of existing bugs and unsoundnesses. Over the last few goal periods, the trait solver went from early prototype to being production use in coherence. The goal for 2025H2 is to prepare it for stabilization.
• The work on evolving trait hierarchies will make it possible to refactor some parts of an existing trait out into a new supertrait so they can be used on their own. This unblocks a number of features where the existing trait is insufficiently general, in particular stabilizing support for custom receiver types, a prior project goal that wound up blocking on this refactoring. This will also make it safer to provide stable traits in the standard library, while preserving the ability to evolve them in the future.
• The work to expand Rust’s Sized hierarchy will permit us to express types that are neither Sized nor ?Sized, such as extern types (which have no size) or ARM’s Scalable Vector Extensions (which have a size that is known at runtime, but not compilation time). This goal builds on RFC #3729 and RFC #3838, authored in previous project goal periods.
• In-place initialization allows creating structs and values that are tied to a particular place in memory. While useful directly for projects doing advanced C interop, it also unblocks expanding dyn Trait to support for async fn and -> impl Trait methods, as compiling such methods requires the ability for the callee to return a future whose size is not known to the caller.

“Flexible, fast(er) compilation”

The “Flexible, fast(er) compilation” initiative focuses on improving Rust’s build system to better serve both specialized use cases and everyday development workflows:

• We are improving compilation performance through (1) parallel compilation in the compiler front-end, which delivers 20-30% faster builds, and (2) making the Cranelift backend production-ready for development use, offering roughly 20% faster code generation compared to LLVM for debug builds.
• We are working to stabilize a core MVP of the -Zbuild-std feature, which allows developers to rebuild the standard library from source with custom compiler flags. This unblocks critical use cases for embedded developers and low-level projects like Rust for Linux, while also enabling improvements like using sanitizers with the standard library or building std with debug information.

“Higher-level Rust”

People generally start using Rust for foundational use cases, where the requirements for performance or reliability make it an obvious choice. But once they get used to it, they often find themselves turning to Rust even for higher-level use cases, like scripting, web services, or even GUI applications. Rust is often “surprisingly tolerable” for these high-level use cases – except for some specific pain points that, while they impact everyone using Rust, hit these use cases particularly hard. We plan two flagship goals this period in this area:

• We aim to stabilize cargo script, a feature that allows single-file Rust programs that embed their dependencies, making it much easier to write small utilities, share code examples, and create reproducible bug reports without the overhead of full Cargo projects.
• We aim to finalize the design of ergonomic ref-counting and to finalize the experimental impl feature so it is ready for beta testing. Ergonomic ref counting makes it less cumbersome to work with ref-counted types like Rc and Arc, particularly in closures.

The full list of 2025H2 goals is available here. We author monthly blog posts about our overall status, but you can also follow the tracking issue for a particular goal to get updates specific to that goal.

About the process

Want to learn more? Check out some of the following:

• RFC #3614, which describes the overall goals and plan
• How to propose a goal of your own
• What it means to be a goal point of contact

Rust project goals 2026

Summary

We are in the process of revising the first draft of the goal slate. New proposals are still accepted but they must already have team consensus and appropriate champions.

This is a draft for the eventual RFC proposing the 2026 goals.

Motivation

The 2026 goal slate consists of 59 project goals. In comparison to prior rounds, we have changed to annual goals rather than six-month goal periods. Annuals goals give us more time to discuss and organize.

Why we set goals

Goals serve multiple purposes.

For would-be contributors, goals are Rust’s front door. If you want to improve Rust - whether that’s a new language feature, better tooling, or fixing a long-standing pain point - the goal process is how you turn that idea into reality. When you propose a goal and teams accept it, you get more than approval. You get a champion from the relevant team who will mentor you, help you navigate the project, and ensure your work gets the review attention it needs. Goals are a contract: you commit to doing the work, the project commits to supporting you.

For users, goals serve as a roadmap, giving you an early picture of what work we expect to get done this year.

For Rust maintainers, goals help to surface interactions across teams. They aid in coordination because people know what work others are aiming to do and where they may need to offer support.

Goals are proposed by contributors and accepted by teams

As an open-source project, Rust’s goal process works differently than a company’s. In a company, leadership sets goals and assigns employees to execute them. Rust doesn’t have employees - we have contributors who volunteer their time and energy. So in our process, goals begin with the contributor: the person (or company) that wants to do the work.

Contributors propose goals; Rust teams accept them. When you propose a goal, you’re saying you’re prepared to invest the time to make it happen. When a team accepts, they’re committing to support that work - doing reviews, engaging in RFC discussions, and providing the guidance needed to land it in Rust.

How these goals were selected

Goal proposals were accepted during the month of January. Many of the goals are continuing goals that are carried over from the previous year, but others goal are new.

In February, an alpha version of this RFC is reviewed with teams. Teams vet the goals to determine if they are realistic and to make sure that goal have champions from the team. A champion is a Rust team member that can will mentor and guide the contributor as they do their work. Champions keep up with progress on the goal, help the champion figure out technical challenges, and also help the contributor to navigate the Rust team(s). Champions also field questions from others in the project who want to understand the goal.

How to follow along with a goal’s progress

Once the Goals RFC is accepted, you can follow along with the progress on a goal in a few different ways:

• Each goal has a tracking issue. Goal contributors and champions are expected to post regular updates. These updates are also posted to Zulip in the #project-goals channel.
• Regular blog posts cover major happenings in goals.

Highlights from the 2026 goals

There are a total of 59 planned for this year. That’s a lot! You can see the complete list, but to help you get a handle on it, we’ve selected a few to highlight. These are goals that will be stabilizing this year or which we think people will be particularly excited to learn about.

Important: You have to understand the nature of a Rust goal. Rust is an open-source project, which means that progress only happens when contributors come and make it happen. When the Rust project declares a goal, that means that (a) contributors, who we call the task owners, have said they want to do the work and (b) members of the Rust team members have promised to support them. Sometimes those task owners are volunteers, sometimes they are paid by a company, and sometimes they supported by grants. But no matter which category they are, if they ultimately are not able to do the work (say, because something else comes up that is higher priority for them in their lives), then the goal won’t happen. That’s ok, there’s always next year!

Cargo improvements

Stabilize cargo-script

Ed Page (point of contact)

Stabilize support for “cargo script”, the ability to have a single file that contains both Rust code and a Cargo.toml.

Language changes

Const Generics

Boxy (point of contact), Niko Matsakis (lang champion), Boxy (types champion)

Extend const generics in two independent directions, both aiming for stabilization:

• adt_const_params: Allow structs and enums as const generic arguments, not just integers.
• min_generic_const_args: Allow associated constants as const generic arguments (e.g., Foo<T::ASSOC_CONST>).

We will also model const generics in a-mir-formality and experiment with upstreaming those changes into the Rust specification. This work also serves as a forcing function for advancing a-mir-formality and its integration into the Rust specification.

Stabilize the next-generation trait solver

lcnr (point of contact), Niko Matsakis (lang champion), lcnr (types champion)

Stabilize -Znext-solver=globally, replacing the existing trait solver implementation entirely.

Sized Hierarchy and Scalable Vectors

David Wood (point of contact), David Wood (compiler champion), Niko Matsakis (lang champion), Amanieu d’Antras (libs-api champion), lcnr (types champion)

Over the next year, we will build on the foundational work from 2025 to stabilize the Sized trait hierarchy and continue nightly support for scalable vectors:

• Stabilize the refined Sized trait hierarchy (without constness), unblocking extern types
• Propose and implement const Sized to support scalable vectors
• Achieve RFC acceptance for [rfcs#3838] (Scalable Vectors)
• Land SVE types and intrinsics in stdarch for nightly experimentation
• Continue addressing stabilization blockers for SVE itself
• Begin design work for supporting the Scalable Matrix Extension (SME)

The const Sized work (Part II of [rfcs#3729]) is deferred to a future goal, allowing us to deliver value sooner through the trait hierarchy stabilization. This future work interacts with ongoing const generics efforts, as const Sized depends on progress in const traits.

Other

Stabilize MemorySanitizer and ThreadSanitizer Support

Jakob Koschel (point of contact)

Stabilize the MemorySanitizer and ThreadSanitizer support. This includes fixing open bugs for the sanitizers to open a path for stabilization and the necessary infrastructure changes to provide precompiled and instrumented standard libraries for the sanitizers.

Wasm Components

Yoshua Wuyts (point of contact)

In 2026 we want to improve the state of Wasm Component support in Rust. This means adding and stabilizing three new compiler targets, as well as begin experimentation with Wasm-specific language features.

Help wanted

This section contains goals that are in need of help.

Looking for contributors

The goals below are looking for a contributor to do the implementation work. The goal summaries include details of the expected time commitment and work duration. If you might be interested in helping with a goal, please join the rust-lang Zulip and post a message in the #project-goals/2026-workshop channel: tell us a bit about yourself, and mention us (the goals team) in that message, like Hello @T-goals!. You could also write to the goals team at goals-team@rust-lang.org! We would love to help you learn more about it.

Box notation for dyn async trait

Niko Matsakis (point of contact), Niko Matsakis (lang champion)

Introduce .box notation and use it to enable dyn dispatch for traits with async methods. The initial scope is foo.method().box where method() returns a dyn-compatible RPITIT. In the future .box could be used more generally but before expanding it we would like to see progress on the work towards in-place initialization.

Contingent on contributor: Niko Matsakis is able to devote 1h/wk to support an experienced contributor or a cohort of contributors in driving this design forward as a lang experiment. This is a challenging problem that will require modifying various parts of the compiler and would also benefit from modeling in a-mir-formality.

Prototype a new set of Cargo “plumbing” commands

Ed Page (point of contact)

1. Refactor Cargo to allow hacks in proposed cargo-plumbing commands to be removed (cargo-plumbing#82).
2. Round out proposed commands (issues)
3. Finalize the message formats (cargo-plumbing#18)

Contingent on contributor: This goal needs contributors to refactor Cargo internals, implement remaining plumbing commands, optimize performance, and iterate on output schemas. The work is primarily in rust-lang/cargo and crate-ci/cargo-plumbing. Estimated time commitment: TBD.

Ergonomic ref-counting: Share trait and move expressions

Niko Matsakis (point of contact), Niko Matsakis (lang champion)

Implement and prototype two foundational improvements for ergonomic ref-counting: (1) a Share trait that semantically identifies types where cloning creates an alias to the same underlying value, and (2) move expressions (move($expr)) that allow precise control over what closures capture and when. These changes lay groundwork for future ergonomic improvements while delivering immediate value, with prototypes targeted for summer 2026.

Contingent on contributor: This is a medium complexity problem. Niko Matsakis would like to mentor this goal with either an experienced contributor or a cohort of folks who know Rust but not the compiler. It is estimated that the goal will take about 6 months to implement for a cohort with minimal compiler hacking experience.

Control over Drop semantics

@thunderseethe (point of contact)

Allow users to easily control the drop semantics of struct fields, letting them change drop order, and disable recursive destructors to make working with cross-language bindings easier.

• Allow cross-language bindings to expose struct fields without compatibility hazards, and
• Make all code that disables default destructor behavior more convenient to use in Rust.

Contingent on contributor: This goal needs a contributor to implement a lang experiment in rustc and write an RFC. The work is a focused compiler feature touching drop semantics and destructor codegen. Estimated time commitment: TBD.

Implement Open Rust Namespace Support

Ed Page (point of contact)

Navigate the cross-team design work to get RFC 3243 implemented.

Contingent on contributor: This goal needs contributors to help complete the implementations in Cargo, rustc, and crates.io. The work spans multiple repositories and involves cross-team coordination. Estimated time commitment: TBD.

Stabilize public/private dependencies

Ed Page (point of contact)

Implement and stabilize the MVP of public dependencies described in RFC #3516. Public dependencies allow crates to declare dependencies whose types are meant to be exposed in the public API.

Contingent on contributor: This goal needs a contributor to work with the compiler team on identifying and implementing the minimal lint subset needed for stabilization. The work spans rustc (lint implementation) and Cargo (dependency metadata). Estimated time commitment: TBD.

Prepare TAIT + RTN for stabilization

Niko Matsakis (point of contact), Niko Matsakis (lang champion), lcnr (types champion)

Prepare TAIT (type alias impl trait) and return type notation (RTN) for stabilization together, giving Rust a coherent story for naming and bounding previously unnameable and unboundable types. TAIT lets users name opaque types like closures, async blocks, and complex iterators without boxing. RTN enables bounds like T::method(..): Send, solving the “Send bound” problem and unblocking widespread use of async fn in traits. This goal also extends RTN to async closures via a new RFC. Full stabilization is blocked on the next-gen trait solver work and is intended to happen late this year.

Contingent on contributor: The majority of the impl work for TAIT and RTN has been done however the syntactic design for RTN and async closures is incomplete. Niko Matsakis is seeking someone willing to help work on the RFC and explore the design space as well as to finalize impl details.

Stabilize Cargo SBOM precursor

Sergey Davidoff (point of contact)

Progress towards an MVP version of Cargo SBOM support by resolving known issues in Cargo’s SBOM precursor feature and finalizing the RFC.

Contingent on contributor: This goal needs contributors to help with testing, resolving known issues in Cargo’s SBOM precursor, and converting downstream tooling like cargo-cyclonedx. The work is primarily in the rust-lang/cargo repository. Estimated time commitment: TBD.

Looking for funds

The goals below are looking for funding. The goal summaries include details of the expected time commitment and work duration. If you might be interested in helping to fund a goal, please join the rust-lang Zulip and post a message in the #project-goals/2026-workshop channel or write to the goals team at goals-team@rust-lang.org.

Improve rustc_codegen_cranelift performance

bjorn3 (point of contact)

This goal aims to improve the rust development experience through faster incremental code generation with rustc_codegen_cranelift. We additionally want to fix several long-standing bugs that currently prevent rustc_codegen_cranelift from being used for popular crates.

Contingent on funding: This goal is contingent on finding funding for this effort.

Control over Drop semantics

@thunderseethe (point of contact)

Allow users to easily control the drop semantics of struct fields, letting them change drop order, and disable recursive destructors to make working with cross-language bindings easier.

• Allow cross-language bindings to expose struct fields without compatibility hazards, and
• Make all code that disables default destructor behavior more convenient to use in Rust.

Contingent on contributor: This goal needs a contributor to implement a lang experiment in rustc and write an RFC. The work is a focused compiler feature touching drop semantics and destructor codegen. Estimated time commitment: TBD.

Stabilize concrete type specialization

Tyler Mandry (point of contact)

Follow stabilization of the new trait solver this year by stabilizing a subset of specializing impls: Impls that follow the [always applicable] rule. This roughly corresponds to specializing trait impls on concrete types.

Stabilize the Try trait

Tyler Mandry (point of contact)

Stabilize the Try trait, which customizes the behavior of the ? operator.

Roadmaps: Looking to the future

Looking past 2026, we have a number of ongoing roadmaps. Roadmaps are collections of goals aimed at achieving a particular purpose.

Each roadmap has a point of contact who can give more technical details. If you’d be interested in helping to accelerate a roadmap with funding, please get in touch with the Rust Foundation who will help coordinate with the open-source project.

Application areas

We’ve organized the roadmaps by the application areas that they benefit (many roadmaps appear in multiple areas).

Network services

Async servers, middleware, and cloud infrastructure.

Systems & embedded

Kernels, drivers, embedded firmware, SIMD, and performance-critical code.

Cross-language interop

FFI, C++/Python/JS bindings, and mixed-language codebases.

Enterprise integration

Build system integration, tooling, and supply chain management for organizations adopting Rust at scale.

Safety-critical & regulated

Automotive, aerospace, medical, and industrial systems requiring certification evidence.

Reference: all goals and roadmaps

This section contains the complete lists of application areas, roadmaps, and goals for 2026:

• A goal is a specific feature or project.
• Goals are collected into larger roadmaps that tell a more complete story. A single goal can be involved in many roadmaps.
• Roadmaps are themselves organized into distinct application areas.

Application areas

Roadmaps

Goals

Just because a goal is listed on this list does not mean the goal has been accepted. The owner of the goal process makes the final decisions on which goals to include and prepares an RFC to ask approval from the teams.

Goals by size

Large goals

Large goals require the engagement of entire team(s). The teams that need to engage with the goal are highlighted in bold.

Goal	PoC	Team	Champion
Arbitrary Self Types	Ding Xiang Fei	types	Jack Huey
		lang-docs	TC
		lang	Tyler Mandry
		libs-api	n/a
		libs	n/a
build-std	David Wood	cargo
		compiler	n/a
		crates-io	n/a
		libs	n/a
Const Generics	Boxy	lang	Niko Matsakis
		types	Boxy
		compiler	n/a
Stabilize Const Traits	Deadbeef	lang
		types	Oliver Scherer
		compiler	n/a
Field Projections	Benno Lossin	lang	Tyler Mandry
		compiler	Ding Xiang Fei
		types	Rémy Rakic
		libs-api	n/a
		libs	n/a
		opsem	n/a
Evolving the standard library API across editions	Amanieu d’Antras	edition
		libs-api
		compiler
		rustdoc
		lang	n/a
		types	n/a
MIR move elimination	Amanieu d’Antras	opsem
		wg-mir-opt
		compiler	n/a
		lang	n/a
Immobile types and guaranteed destructors	Jack Huey	lang
		types	lcnr
Stabilize the next-generation trait solver	lcnr	types	lcnr
		lang	Niko Matsakis
Stabilize the polonius alpha analysis	Rémy Rakic	types	Jack Huey
Redesigning super let: Flexible Temporary Lifetime Extension	dianne	lang
		compiler	n/a
		libs	n/a
reflection and comptime	Oliver Scherer	lang	Scott McMurray
		compiler	Oliver Scherer
		libs-api	Josh Triplett
		types	n/a
Normative Documentation for Sound unsafe Rust	Pete LeVasseur	opsem	Ralf Jung
		lang-docs	n/a
		lang	n/a
		libs-api	n/a
Stabilize concrete type specialization	Tyler Mandry	types
		lang
		compiler	n/a
		libs	n/a
		opsem	n/a
Stabilize FLS Release Cadence	Pete LeVasseur	fls
		spec	n/a

Medium goals

Medium goals require support from an individual, the team champion.

Goal	PoC	Team	Champion
Box notation for dyn async trait		compiler
		lang	Niko Matsakis
		types	n/a
asm_const_ptr	Alice Ryhl	lang-docs
		lang
		libs-api	n/a
		libs	n/a
Assumptions on Binders	Boxy	types	Boxy
Async Future Memory Optimisation	Ding Xiang Fei	compiler
Async statemachine optimisation	@diondokter	compiler
BorrowSanitizer	Ian McCormack	compiler	Ralf Jung
		opsem	Ralf Jung
		infra	n/a
		lang	n/a
Cargo cross workspace cache	Ross Sullivan	cargo	Ed Page
cfg(no_fp_fmt_parse)	@todo	lang-docs
		lang
		libs-api	n/a
		libs	n/a
Crate Slicing for Faster Fresh Builds	@yijunyu	cargo
		compiler
		lang	n/a
		rust-analyzer	n/a
		types	n/a
Ergonomic ref-counting: Share trait and move expressions		lang	Niko Matsakis
		compiler	n/a
		lang-docs	n/a
		libs-api	n/a
Case study for experimental language specification, with integration into project teams and processes	Jack Huey	lang	Josh Triplett
		types	Jack Huey
		spec	n/a
Project goal - High-Level ML optimizations	Manuel Drehwald	compiler	Oliver Scherer
		lang	TC
		infra	n/a
Improve rustc_codegen_cranelift performance	bjorn3	compiler
		cargo	n/a
In-place initialization	Alice Ryhl	lang
Incremental Systems Rethought	Alejandra González	compiler
C++/Rust Interop Problem Space Mapping	Jon Bauman	opsem
		compiler	n/a
		lang	n/a
		libs-api	n/a
Control over Drop semantics		lang
		compiler	n/a
		opsem	n/a
		types	n/a
Implement and Maintain MC/DC Coverage Support	@RenjiSann	compiler
		project-stable-mir
		infra	n/a
Open Enums	@kupiakos	compiler
		lang
		libs	n/a
		opsem	n/a
		types	n/a
Nightly support for function overloading in FFI bindings	@ssbr	lang
		compiler	n/a
		libs-api	n/a
		types	n/a
Continue Experimentation with Pin Ergonomics	Frank King	compiler	Oliver Scherer
		lang	TC
		types	Oliver Scherer
Stabilize public/private dependencies		compiler
		cargo	n/a
Reborrow traits	Aapo Alasuutari	lang	Tyler Mandry
		compiler	n/a
		types	n/a
Prepare TAIT + RTN for stabilization		lang	Niko Matsakis
		types	lcnr
Stabilize Rust for Linux compiler features	Tomas Sedovic	compiler	Wesley Wiser
Sized Hierarchy and Scalable Vectors	David Wood	lang	Niko Matsakis
		libs-api	Amanieu d’Antras
		types	lcnr
		compiler	n/a
Stabilize MemorySanitizer and ThreadSanitizer Support	Jakob Koschel	bootstrap
		compiler
		project-exploit-mitigations
		infra	n/a
Stabilize Cargo SBOM precursor		cargo
Stabilize the Try trait	Tyler Mandry	lang
		libs
		compiler	n/a
		types	n/a
Implement Supertrait auto impl	Tyler Mandry	lang
		types	Boxy
used_with_arg	@todo	lang-docs
		lang
		libs-api	n/a
		libs	n/a

Small goals

Small goals are covered by standard team processes and do not require dedicated support from anyone.

Goal	PoC	Team	Champion
Expanding a-mir-formality to work better as a Rust type system spec	Jack Huey	lang-docs	n/a
		spec	n/a
		types	n/a
Prototype a new set of Cargo “plumbing” commands		cargo	n/a
Stabilize cargo-script	Ed Page	cargo	n/a
		compiler	n/a
		lang	n/a
		rustdoc	n/a
Continue resolving cargo-semver-checks blockers for merging into cargo	Predrag Gruevski	cargo	n/a
		rustdoc	n/a
Interactive cargo-tree: TUI for Cargo’s dependency graph visualization	@orhun	cargo	n/a
libc 1.0 release readiness	Yuki Okushi	crate-maintainers	n/a
Finish the libtest json output experiment	Ed Page	cargo	n/a
		libs-api	n/a
		testing-devex	n/a
Implement Open Rust Namespace Support		cargo	n/a
		compiler	n/a
Establish a Spot for Safety-Critical Lints in Clippy	Pete LeVasseur	clippy	n/a
Stabilizing f16	Folkert de Vries	compiler	n/a
		lang	n/a
		libs-api	n/a
Type System Documentation	Boxy	types	n/a
Establish a User Research Team	Niko Matsakis	leadership-council	n/a
Wasm Components	Yoshua Wuyts	compiler	n/a
		lang	n/a
		libs	n/a

Goals by champion

Goals by team

The following table highlights the support level requested from each affected team. Each goal specifies the level of involvement needed:

• Small: The team only needs to do routine activities (e.g., reviewing a few small PRs).
• Medium: Dedicated support from one team member, but the rest of the team doesn’t need to be heavily involved.
• Large: Deeper review and involvement from the entire team (e.g., design meetings, complex RFCs).

“Small” asks require someone on the team to “second” the goal. “Medium” and “Large” asks require a dedicated champion from the team.

bootstrap team

cargo team

*1: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and many implementation patches (from here)

*2: Discussion on cargo integration options (from here)

*3: Design and code reviews (from here)

*4: Alignment on direction, possible integration help and review. (from here)

*5: Discussion and moral support (from here)

*6: PR reviews for Cargo changes; design discussions (from here)

*7: In case we end up pursuing JITing as a way to improve performance that will eventually need native integration with cargo run. For now we’re just prototyping, and so the occasional vibe check should be sufficient (from here)

clippy team

*1: Initial onboarding support for SCRC contributors; guidance on lint design (from here)

compiler team

*1: An implementer, design discussions, PR review (from here)

*2: Consultation on approach feasibility and soundness concerns (from here)

*3: Most will be review work, but pushing optimisations to the max will possibly touch on some controversial points that need discussion (from here)

*4: Champion: Ralf Jung. Design discussions, PR review, and upstream integration. (from here)

*5: Reviews of big changes needed; also looking for implementation help (from here)

*6: Depending on what ways we end up pursuing, we might need no rustc side changes at all or medium sized changes. (from here)

*7: Is this Small or Medium? Does it need a champion? (from here)

*8: My changes should be contained to few places in the compiler. Potentially one frontend macro/intrinsic, and otherwise almost exclusively in the backend. (from here)

*9: Review of implementation PRs; guidance on architecture to avoid previous maintenance issues; input on Stable MIR extension feasibility (from here)

*10: Design discussions and implementation review. (from here)

*11: May escalate to medium depending on how the feature design turns out. (from here)

*12: Design discussions, PR review (from here)

*13: Reviewing any further compiler changes (from here)

*14: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)

*15: Standard reviews for trait implementation PRs (from here)

*16: Standard reviews for stabilization and SVE work (from here)

*17: New targets will need review and approval (from here)

*18: Most complexity is in the type system (from here)

crate-maintainers team

crates-io team

*1: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)

edition team

*1: Review the feasibility of this proposal as well as the specific API changes. (from here)

fls team

*1: Core work of authoring and releasing FLS versions on schedule (from here)

infra team

*1: I will work with Jakub Beránek to add more bootstrap options to build and configure MLIR (an LLVM subproject) (from here)

*2: CI support for MC/DC testing (from here)

lang team

*1: Would need a design meeting and RFC review. (from here)

*2: Design session needed to work through design (from here)

*3: Stabilization decisions, directional alignment (from here)

*4: Design meeting, experiment (from here)

*5: Aiming for two design meetings; large language feature (from here)

*6: Semantics, syntax, and stabilization decisions (from here)

*7: Review and accept a design space RFC (from here)

*8: RFC review, design discussions (from here)

*9: Champion and (ideally) a lang meeting (from here)

*10: Stabilization decision for user facing changes (from here)

*11: Reviews, Lang/RfL meetings (from here)

*12: Reviews, Lang/RfL meetings (from here)

*13: Reviews, Lang/RfL meetings (from here)

*14: Vibe check and RFC review (from here)

*15: Continued experiment support, design feedback (from here)

*16: RFC decision for [rfcs#3838], stabilization sign-off (from here)

*17: Reviews, Lang/RfL meetings (from here)

*18: Design meeting Experiment (from here)

*19: Resolve design concerns like #[override] and review stabilization (from here)

*20: Discussions to understand which parts of gpu programming and std::offload are problematic wrt. stabilization, from a lang perspective. Non-blocking, since we are not rushing stabilization. (from here)

*21: Team aligned already on the shape of the feature (from here)

*22: Discussion on review of research methodology and findings (from here)

*23: Champion: Tyler Mandry. General support and guidance. (from here)

*24: Stabilization discussions (from here)

*25: Experimentation with native Wasm features will need approval. May become “medium” if we are somehow really successful. (from here)

*26: Feedback on language semantics questions as needed (from here)

*27: Review of the feature and lang implications. (from here)

*28: occasionally being fast-tracked would be nice (from here)

lang-docs team

*1: Reviews, Lang/RfL meetings (from here)

*2: Reviews, Lang/RfL meetings (from here)

*3: Reviews, Lang/RfL meetings (from here)

*4: Reviews, Lang/RfL meetings (from here)

*5: Standard PR reviews for Rust Reference (from here)

*6: General discussion of shape of integration of a-mir-formality into reference (from here)

leadership-council team

*1: Org decision to establish team, ongoing coordination (from here)

libs team

*1: Since super let affects the standard library, the library team should be on-board with any new directions it takes. Additionally, library team review may be required for changes to pin!’s implementation. (from here)

*2: Small reviews of library PRs (implementing FP for core & std types) (from here)

*3: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)

*4: Threading support will need review (from here)

libs-api team

*1: Determine what API changes should be made across editions. (from here)

*2: Review RFC; review and approve stdarch SVE APIs (from here)

*3: Reviews of RFC and API surface area (from here)

*4: Would like to know if they have use cases for overloading in standard Rust, or if there are certain approaches they would like better. May be involved if experiment involves library surface area (e.g. Fn traits) (from here)

*5: PR reviews for core/std public documentation; feedback on approach. (from here)

opsem team

*1: Review unsafe patterns, establish safety contracts, guide documentation (from here)

*2: Problem statement review (from here)

*3: Doc changes if necessary (from here)

*4: Small reviews of RFC and/or compiler PRs (from here)

project-exploit-mitigations team

project-stable-mir team

*1: Consultation on extending Stable MIR with syntactic structure; review of any proposed API additions (if this approach is chosen) (from here)

rust-analyzer team

*1: Discussion on rust-analyzer integration potential (from here)

rustdoc team

*1: Figure out how such API changes should be presented in the API docs. (from here)

*2: Discussion and moral support (from here)

*3: Design decision and PR review (from here)

spec team

*1: Alignment on release cadence goal (from here)

*2: General discussion on how this may align with other efforts to specify Rust. (from here)

*3: General discussion of integration of a-mir-formality with reference (from here)

testing-devex team

*1: Design discussions and review (from here)

types team

*1: Involved in implementation + review (from here)

*2: a-mir-formality modeling, design alignment (from here)

*3: Stabilization decision, ongoing review work (from here)

*4: Review of type-system stabilization/implementation (from here)

*5: Implementation design and sign-off (from here)

*6: Review future extensions for plausibility, soundness, and stabilization (from here)

*7: Design review, stabilization decision, reviews from Jack Huey and Matthew Jasper (from here)

*8: implementation/reviews/deciding on a design (from here)

*9: Stabilization report review, TAIT interactions (from here)

*10: Collaborating on a-mir-formality on the borrow checker integration; small reviews of RFC and/or compiler PRs (from here)

*11: Type System implementation and stabilization sign-off (from here)

*12: Evaluate potential changes to (experimental) reference in routine team decisions (from here)

*13: Want to ensure that the feature “fits within the lines” of a simple desugaring, still some possible type-system impl work (from here)

*14: Discussion and moral support (from here)

*15: Consultation on trait coherence requirements for slicing (from here)

*16: General discussion on any additional type-system changes (from here)

*17: Standard reviews for trait implementation PRs (from here)

*18: No dedicated reviewer needed/given, but tracking issue should note the needed for dedicated types review prior to stabilization (from here)

*19: Members may have comments/thoughts on direction and priorities; Review work for a-mir-formality (from here)

*20: Review of any changes to HIR ty lowering or method resolution (from here)

*21: May have changes to dyn-compatibility rules (from here)

wg-mir-opt team

Beyond the &

Summary

Smart pointers that feel as natural as & and &mut.

Motivation

The status quo

One of Rust’s core value propositions is that it’s a “library-based language”—libraries can build abstractions that feel built-in to the language even when they’re not. Smart pointer types like Rc and Arc are prime examples, implemented purely in the standard library yet feeling like native language features.

However, Rust’s built-in reference types (&T and &mut T) have special capabilities that user-defined smart pointers cannot replicate:

• Reborrowing: When you pass a &mut T to a function, Rust automatically reborrows it so you can use it again afterward. But Option<&mut T> or custom smart pointers require awkward .as_deref_mut() or .reborrow() calls—and values derived from these reborrows cannot be returned from the function.
• Field projection: Writing &x.field gives you &Field—the borrow checker tracks that you’re only borrowing part of the struct. Custom pointer types like NonNull<T> or ArcRef<T> have no equivalent; you can’t write arc_ref.field and get back an ArcRef<Field>.
• In-place initialization: Creating a value directly at its final memory location—crucial for unmovable types and large structs—requires complex macro-based solutions because the language has no native support.

This creates a “second-class citizen” problem: custom pointer types can never provide the same ergonomic experience as built-in references, limiting Rust’s promise of zero-cost abstractions.

What we are shooting for

We want user-defined smart pointers to be truly indistinguishable from built-in references in terms of syntax and ergonomics. When you use an ArcRef<T> or Pin<&mut T>, it should feel just like using &T or &mut T:

• Automatic reborrowing for any pointer type that opts in, with derived values returnable from functions
• Field projection that lets you write ptr.field and get back a pointer to the field, with full borrow-checker integration
• Language-level in-place initialization that’s more ergonomic than what macros can achieve

Key use cases

• Rust for Linux: The kernel uses custom smart pointer types (Arc, ArcBorrow, Ref) to express ownership and borrowing patterns that don’t map directly to Rust’s built-in references. Field projection and reborrowing would make these types dramatically more ergonomic.
• Cross-language interop: FFI wrappers like PyRef<T> (Python) or CppMutRef<T> (C++) represent references into foreign runtimes. These should feel as natural as native Rust references when accessing fields or passing to functions.
• MaybeUninit initialization: Safely initializing structs field-by-field through &mut MaybeUninit<T> is currently verbose and error-prone. Field projection would let you write uninit.field and get &mut MaybeUninit<Field>.
• Interior mutability: Types like cell::Ref<T> and RefMut<T> wrap borrowed data but lose the ability to project into fields. You can’t write ref_mut.field to get a RefMut<Field>.
• Volatile and atomic access: Low-level code working with memory-mapped I/O needs pointer types like VolatilePtr<T> that preserve access semantics through field projection.

Design axioms

• Generalize and extend the basic operations of Rust. Build on existing models of how the language works while relaxing restrictions. Fix expressiveness gaps in the base paradigm, rather than inventing new paradigms altogether.
• Enable abstractions that are powerful, transparent, and ergonomic to use. These abstractions should allow code to be clearer in its purpose and behavior than it is without them.
• Ship iteratively. Ship building blocks that unblock existing use cases and new experimentation. Don’t block on full generality and ease of use when that can be done in the future.
• Design holistically. Look for ways to accommodate further generality in our designs, even if we don’t expose that generality at first.

2026 goals

Frequently asked questions

How do these goals relate to each other?

The goals are complementary but largely independent:

• Reborrow traits address the “automatic reborrowing” problem, providing the general mechanism that types can opt into.
• Field projections provides the broader “place operations” framework that encompasses projection, borrowing, and reading/writing through custom pointer types.
• In-place initialization tackles a related but distinct problem: creating values that can’t be moved.

What types will benefit from this work?

A non-exhaustive list: NonNull<T>, *const T and *mut T, &mut MaybeUninit<T>, cell::Ref and RefMut, ArcRef<T>, FFI pointer wrappers like PyRef<T> or CppMutRef<T>, volatile pointers, and many more.

Is this the same as the “custom receivers” feature?

Related but distinct. Custom receivers (RFC 3519) allow methods with self: MyPtr<Self>. The “Beyond the &” work goes further: making those custom pointer types feel like native references through automatic reborrowing, field access, and borrow checker integration.

Building blocks

Summary

Expose Cargo and Rust’s internal infrastructure as stable, composable building blocks for tooling authors and power users.

Motivation

The status quo

Rust’s tooling ecosystem includes hundreds of third-party tools built on top of Cargo, rustc, and the standard library. Tools like cargo-nextest, rust-analyzer, and cargo-deny extend what ships with Rust. But tool authors face significant friction:

• Cargo is designed for humans, not scripts. When tools need dependency information, feature resolution, or build graph data, they must parse human-readable output or use cargo metadata (which has known limitations). There’s no stable programmatic interface.

• libtest’s output is unstable. The standard test harness provides no stable machine-readable format. When --format json was accidentally stabilized and then reverted to nightly-only, it revealed how many tools depended on it.

• Building std requires nightly. The -Zbuild-std flag lets users rebuild the standard library with custom settings, but it remains unstable. Embedded developers and those on tier-3 targets must use nightly.

The result: tool authors spend effort reverse-engineering Cargo’s behavior and building workarounds for missing capabilities.

What we are shooting for

By the end of 2026:

• Cargo plumbing commands are prototyped and validated. External experimentation with machine-readable commands that expose Cargo’s operations, with a path toward eventual inclusion in Cargo. Just as Git distinguishes “porcelain” (user-facing) from “plumbing” (scriptable), this work explores building blocks for programmatic access.

• libtest JSON output experiment is complete. The experiment concludes with a proposal for stable JSON output, enabling better test runners and IDE integration.

• build-std implementation is underway. RFCs are accepted and implementation has begun, moving toward eventual stabilization of rebuilding the standard library with custom configurations.

• Interactive dependency exploration is prototyped. External tooling demonstrates interactive navigation of dependency graphs, with preparation for eventual Cargo integration.

Key use cases

• Custom test runners: Tools like cargo-nextest rely on stable JSON output for parallel execution and better failure reporting.

• Build system integration: Organizations using Buck, Bazel, or custom systems need reliable programmatic access to Cargo’s dependency and build information.

• IDE tooling: rust-analyzer needs fast, reliable project structure and dependency information.

• Embedded development: Developers working on embedded systems or kernel development need to rebuild std with specific configurations on stable Rust.

Design axioms

• Separate porcelain from plumbing. User-facing commands remain focused on usability. Programmatic access comes through dedicated plumbing commands with stable schemas.

• Stable means stable. When we stabilize an interface, tool authors can depend on it without checking Rust versions.

• Expose the truth. Plumbing commands expose what Cargo actually knows, not a simplified approximation that might miss edge cases.

• Prototype externally, integrate when ready. New capabilities start as external tools where iteration is fast, then integrate into Cargo once designs stabilize.

2026 goals

Goal	Point of contact	Task Owners and Champions
build-std	David Wood
Prototype a new set of Cargo “plumbing” commands
Interactive cargo-tree: TUI for Cargo’s dependency graph visualization	@orhun
Finish the libtest json output experiment	Ed Page

Frequently asked questions

How do these goals relate to each other?

The goals share a vision but are largely independent:

• build-std focuses on completing RFCs and beginning implementation for the compiler and standard library.
• cargo-plumbing prototypes programmatic access to Cargo’s operations as an external tool.
• libtest-json completes the experiment toward stable test harness output.
• interactive-cargo-tree prototypes improved dependency exploration UX externally.

Each delivers value independently, though cargo-plumbing may eventually provide APIs that other tools use.

Who benefits from this work?

Primarily tooling authors, large organizations integrating Rust into build systems, embedded developers, IDE developers, and power users. Indirectly, all Rust users benefit because better infrastructure enables better tools.

Why not expose Cargo as a library?

Cargo-as-a-library has significant challenges: API stability commitments, versioning complexity, and architectural constraints. Plumbing commands provide a practical near-term solution with clear boundaries and schema versioning.

Constify all the things

Summary

Richer const generics and compile-time reflection that works without derives.

Motivation

The status quo

Rust’s compile-time capabilities are powerful but incomplete. const fn enables compile-time evaluation, but users repeatedly hit limitations when trying to use it for real work:

• Const generics only support primitive types. You can write Array<T, 4> but not Array<T, Dimensions { width: 4, height: 4 }>. Using associated constants as const parameters (Buffer<T, T::SIZE>) also doesn’t work. These limitations force workarounds or abandoning const generics entirely.

• Reflection requires derives on every type. Libraries for serialization, logging, or reflection need users to add derives for each type they want to work with. This creates ecosystem friction: crate authors must choose which libraries to support, users must add boilerplate for each library, and new libraries can’t reach existing types.

• Proc macros are the only option for code generation. When you need compile-time code generation, proc macros work but are difficult to debug, can’t access type information, and add compile-time overhead.

Extending const generics and adding compile-time reflection would address all three limitations, letting users write normal Rust code that inspects types and runs at compile time.

What we are shooting for

Stable by end of 2026:

• Const generics accept structs and enums. Write Array<T, Dimensions { width: 4, height: 4 }> and have it work. Use associated constants like Buffer<T, T::SIZE>.

RFC by end of 2026:

• Reflection without derives. An experimental comptime reflection system will be available on nightly and validated against libraries like bevy_reflect and facet. We aim to have an RFC merged defining the stabilization path.

Key use cases

• Zero-boilerplate serialization: serialize(&my_struct) works for any struct without derives. The library inspects field types at compile time.

• Game engine reflection: Engines like Bevy can inspect any type’s structure directly, making #[derive(Component)] optional.

• Dimension-checked numerics: Libraries encode physical dimensions in const generic structs, providing compile-time verification of unit calculations.

• Protocol buffer generation: Libraries work directly with Rust structs at compile time, without external code generators.

2026 goals

Frequently asked questions

How do these goals relate to each other?

• Const generics extends what values can be used as compile-time parameters—foundational for many advanced patterns.

• Reflection and comptime provides the ability to inspect types at compile time, enabling libraries that work without derives.

Together they transform what’s possible at compile time: const generics let you parameterize by complex values, reflection lets you adapt to any type’s structure.

How does reflection differ from proc macros?

Proc macros operate on syntax (tokens) before type checking. Reflection operates on types during const evaluation. Reflection can see actual type information (field types, sizes, layouts), is debuggable with standard tools, and doesn’t require proc-macro compilation overhead.

Will reflection make derives obsolete?

Not obsolete, but often optional. Derives generate specialized code and can be more efficient. Reflection offers less boilerplate with potentially some runtime cost. Many libraries will likely offer both modes.

Just add async

Summary

Writing async Rust should be a natural extension of sync Rust: take your sync code, sprinkle some async and await keywords around in logical places, follow the compiler’s guidance, and wind up with working code.

Motivation

The status quo

Async Rust is widely used

The promise of tight tail latency, low memory usage, and high-level reliable code has made Rust, and async Rust in particular, a popular choice for network services. Rust is now widely used at all levels, from superscalars like Amazon and Microsoft, to simple CRUD apps built on FAAS platforms like Lambda or Azure Functions, to low-level networking on embedded devices.

But Async Rust doesn’t support standard Rust patterns

Despite this success, async Rust is widely seen as qualitatively harder than sync Rust. Not just more complex, but a different kind of challenge:

“I feel like there’s a ramp in learning and then there’s a jump and then there’s async over here. And so the goal is to get enough excitement about Rust to where you can jump the chasm of sadness and land on the async Rust side.” (from the Rust Vision Doc interviews)

The problem isn’t async concepts themselves. Developers understand concurrency (well, mostly). The problem is that patterns which work in sync Rust don’t transfer to async:

• Traits: async fn in traits is stable, but you can’t use &dyn Trait with async methods, and there’s no way to require that an impl returns a Send future.
• Closures: Async closures are stable, but compiler bugs frequently report invalid Send errors, and the trait limitations above make them hard to use in practice.
• Recursion: In sync Rust, recursion just works. In async Rust, it requires arcane signatures with explicit lifetimes, Box, dyn Future, and Pin.
• Scoped patterns: Sync Rust has std::thread::scope for borrowing into spawned threads. Async spawn APIs require 'static, forcing Arc everywhere.
• Drop: Destructors are sync-only. Resources that need async cleanup (database connections, network sessions) can’t clean up properly in Drop.

Each issue has workarounds. But the workarounds require knowledge that doesn’t transfer from sync Rust, and the compiler doesn’t guide you to them. The result: developers who would otherwise build a network service in Rust hit these walls and wonder if it’s worth the trouble.

The ecosystem is waiting too. Libraries like Tower remain on 0.x because they can’t express the APIs they need. Tower’s Service trait predates async fn in traits and uses complex workarounds. The maintainers want to ship a cleaner design, but they’re blocked on language features. Particularly the ability to define one trait that works with both Send and non-Send futures. So Tower waits, and the middleware ecosystem built on it stays in flux.

What we are shooting for

The goal is “Just add async”: patterns that work in sync Rust should work in async Rust without requiring workarounds, restructuring, or arcane incantations. When async does require something extra (like explicit boxing for dyn dispatch), the compiler guides you with clear, actionable errors. Not walls of opaque type errors.

There should be straightforward equivalents for all the “rudiments of Rust”:

• Inherent async function definitions and calls to those functions
• Async closures
• Static trait dispatch for traits with async functions
• Generic functions that make use of those traits (proposed for 2026)
• Dynamic trait dispatch (proposed for 2026)
• Iterators (requires a stream trait design and other details)
• Convenient ways to write recursive functions
• Scoped parallelism (requires immobile types and guaranteed destructors, proposed for 2026)
• Async drop and resource cleanup (requires immobile types and guaranteed destructors, proposed for 2026)

Key use cases

• Network service development: Backend services, API servers, data pipelines. The most common async use case. In this scenario, allocation is acceptable. Performance bounds vary by application but consistency is often more important than absolute level of performance.

• Middleware and composable abstractions: Libraries like Tower can define Service traits that work across runtimes (work-stealing and thread-per-core) without complex workarounds.

Design axioms

• Sync patterns should transfer. If a pattern works in sync Rust, it should work in async Rust. When async requires something extra, the compiler should guide you there.

• Server-first, but not server-only. We focus on server and application use cases to ship complete workflows now. But designs should leave space for users with stricter requirements. Features that allocate today can be extended with custom allocators or in-place initialization later. We’re not closing doors, we’re opening the first one.

• Unblock the ecosystem, enable experimentation. The goal isn’t just language features. It’s enabling libraries like Tower to ship stable APIs, and creating space for exploration of harder problems (in-place initialization, structured concurrency) without blocking on them. Ship end-to-end workflows that work today while leaving room for the designs to evolve.

2026 goals

Goal	Point of contact	Task Owners and Champions
Box notation for dyn async trait		Niko Matsakis (lang)
Ergonomic ref-counting: Share trait and move expressions		Niko Matsakis (lang)
Immobile types and guaranteed destructors	Jack Huey	lcnr (types)
Stabilize the next-generation trait solver	lcnr	Niko Matsakis (lang), lcnr (types)
Prepare TAIT + RTN for stabilization		Niko Matsakis (lang), lcnr (types)

Frequently asked questions

What am I agreeing to by accepting this theme?

Accepting this roadmap means agreeing that:

1. These problems matter. The gaps between sync and async Rust are real and worth fixing.
2. This direction is right. Closing these gaps so “Just add async” works is the right goal.
3. Server-first is the right prioritization. We ship end-to-end workflows for server/application environments first, with designs that leave space for stricter requirements later.

It does not mean agreeing to specific syntax (like .box) or implementation details. Those will be decided in individual goal RFCs.

What about async iterators / streams?

Async iteration is part of this theme’s vision, but not a 2026 focus. The 2026 goals target the foundational work: getting async fn in traits and closures fully working. That’s enough scope for one year. Exploring streams fully will require those foundations plus guaranteed destructors (because streams interact with structured concurrency and cancellation). Once the 2026 work lands, streams become much more tractable.

How do the goals in this theme relate to each other?

The four 2026 goals are largely independent:

• RTN enables generic async code and is already RFC’d, waiting on trait solver work
• AFIDT / .box notation enables dyn dispatch for async traits
• Ergonomic ref-counting addresses closure capture pain that’s amplified by async’s 'static spawn requirements
• Immobile types and guaranteed destructors enables scoped spawn and async drop by letting types opt out of being moved or forgotten

RTN and AFIDT share a dependency on the next-generation trait solver, which is being worked on separately.

Rust for Linux

Summary

Rust is now an integral part of the Linux kernel. There are mainline drivers built in it, tooling and it’s even directly in the kernel itself.

The Rust for Linux project is leading the development and the Rust Project is helping to facilitate some of the coordination.

While the project is built on a stable version of the Rust compiler, it relies on language features that are unstable (via the #![feature(...)] declarations). Ultimately, we want to stabilize all the features Rust for Linux relies on and support any platform that Linux itself supports.

Motivation

The status quo

The Rust for Linux page has a great overview of what’s supported and being worked on at the moment.

The project has to use the feature-gated functionality and it’s currently limited to platforms that LLVM supports.

The Rust Project has a regular meeting with the Rust for Linux folks every two weeks and that is where we synchronise on status and discuss any potential road blocks and issues or topics that came out.

We have representatives from the Language and Compiler teams present.

We have also been tracking the coordination through Project goals and this is a continuation of that effort.

What we are shooting for

• Build Linux kernel releases using the stable Rust language (no feature gates).
• Support all the targets that Linux supports.
• Address the long tail of features Rust for Linux needs

Key use cases

• Reduce the risk of critical errors: By compartmentalising the unsafe parts of the code base and having a clear boundary, we can build code that will have fewer bugs. We can rewrite notoriously tricky sections and provide better primitives.

• Improve code quality across the kernel: In addition to the direct benefits of the Rust code, the Kernel is seeing improvements in the C side as well. We are seeing improvements of existing APIs in terms of const-ness, clarity and safety. Even people working solely with C have started pushing for better API documentation. Having Rust with the constantly maintained high bar that the Rust for Linux folks started results in a better codebase overall.

• Bring in new contributors: It is a frequent theme within the Rust community that people who would never felt confident writing C dive into low-level topics and able to learn, experiment and ship code that is safe to be integrated into larger systems.

Design axioms

Don’t let perfect be the enemy of good™: The primary goal is to offer stable support for the particular use cases that the Linux kernel requires. Wherever possible we aim to stabilize features completely, but if necessary, we can try to stabilize a subset of the functionality that meets the kernel developers’ needs while leaving other aspects unstable.

2026 Goals

compiler_builtins TODO(tomassedovic) the previous issue also lists compiler builtins. What are those?

Frequently asked questions

TODO

• when is this done? (A: when the work here is all stable?)
• how do the goals relate to each other (note the interdependencies)

Safety-Critical Rust

Summary

Make Rust viable for certified safety-critical systems by delivering coverage, specification, linting, and unsafe documentation foundations.

Motivation

The status quo

Engineers building software under functional safety standards need auditable evidence and predictable tooling. The major standards families include:

This includes OEMs, suppliers, integrators, and toolchain vendors. Safety cases must reference a specification for the language being used, and the toolchain must produce evidence that assessors accept.

What these teams need most:

• Coverage tooling. MC/DC reports that assessors accept.
• A specification that tracks stable releases. So safety cases can reference current language features via the FLS.
• Continued progress on unsafe documentation. The Reference, Rustonomicon, and standard library docs have improved substantially over the years, but gaps remain for common patterns.
• Stable foundations. Product lifetimes of 10-20 years require confidence in toolchain support and MSRV conventions.

Teams at SIL 2 and ASIL B are shipping Rust today. These deliverables reduce the workarounds they need and create a path to higher integrity levels.

What we are shooting for

We are building a capability ladder that unlocks Rust at increasing safety-integrity levels. The 2026 focus is the foundation, while keeping a clear path to higher tiers.

• Foundation (ASIL A/B, SIL 1/2, DO-178C Level C). Stable branch/DC coverage baselines and predictable FLS releases, plus initial safety-critical linting to enforce Safety-Critical Rust Consortium coding standards.
• Intermediate (ASIL C, SIL 3, DO-178C Level B). Normative unsafe pattern documentation and expanded lint coverage, with coordination for mixed-language interop and async runtime patterns.
• Highest integrity (ASIL D, SIL 4, DO-178C Level A). MC/DC coverage in rustc and formal-methods coordination toward contracts, semantics documentation, and verified tooling.

Key use cases

• Certification evidence: Generate coverage and spec references that auditors accept.
• Qualified toolchains: Tool vendors can qualify rustc/Clippy with predictable releases and lint sets.
• Mixed-language systems: Integrate Rust into C and C++ stacks with well-defined unsafe contracts.
• Long-lived products: Maintain 10-20 year systems with stable MSRV and documentation baselines.

Design axioms

• Evidence first. Prioritize deliverables that produce audit-ready evidence.
• Use standard tooling. Improve rustc, Clippy, and core docs rather than forks.
• Ship a ladder. Foundations first, with an explicit path to higher integrity levels.
• Document safety contracts. unsafe patterns must have normative, citable guidance.

2026 goals

Frequently asked questions

How do these goals relate to each other?

They form a coherent evidence chain: FLS releases provide a citable specification, unsafe documentation defines safety contracts, Clippy lints enforce coding guidelines, and MC/DC coverage produces the evidence required at the highest integrity levels.

Does this certify Rust for safety-critical use?

No. Certification is per product and toolchain. These goals deliver the foundations that make qualification and certification feasible without bespoke tooling.

Why focus on foundations in 2026?

Teams at lower integrity levels are already shipping Rust and need practical improvements now. The foundation work also makes the higher-integrity goals achievable later.

Secure your supply chain

Summary

Know exactly what code ships in your binaries, catch breaking changes before they break your users, and keep your public API under control.

Motivation

The status quo

Every Rust project is built on a foundation of dependencies—the average crate pulls in dozens of transitive dependencies. This is powerful, but it means you’re responsible for code you didn’t write and may not fully understand.

Today, Rust developers face three challenges:

• You don’t know what’s actually in your binary. cargo metadata reports all possible dependencies across all configurations, not what actually got compiled. When a vulnerability is announced, you need to know whether your production binary contains the affected code. Regulatory requirements are increasing: the US Executive Order 14028 requires Software Bills of Materials (SBOMs) for federal software, and the EU Cyber Resilience Act mandates SBOMs for products sold in Europe starting in 2027.

• Breaking changes slip through. Research shows accidental SemVer violations occur in roughly 3% of releases. When you publish 1.2.3, you might not realize you’ve removed a method or tightened a trait bound. Users find out when cargo update breaks their build.

• Dependencies leak into your public API. When you write pub fn process(data: some_crate::Data), that crate becomes part of your API contract. But Cargo doesn’t distinguish between dependencies you intentionally expose and ones that accidentally surface.

What we are shooting for

By the end of 2026:

• Accurate SBOMs on stable Rust. cargo build produces machine-readable metadata about exactly which crate versions were compiled, in standard formats like CycloneDX or SPDX. When a CVE drops, you can query whether your binary contains the affected code.

• Better tooling for catching SemVer violations. cargo-semver-checks continues toward integration with cargo publish, with progress on type-checking lints and cross-crate analysis. Today, you can run it in CI to catch common breaking changes before they reach users.

• Public vs private dependencies are explicit. Marking a dependency as “private” means it can’t appear in your public interface. If you accidentally expose a private dependency’s type, you get a warning.

Key use cases

• Regulatory compliance: Generate accurate SBOMs directly from the build process for US federal or EU market requirements.

• Vulnerability response: Query SBOM data to determine which deployed binaries contain affected code.

• Confident publishing: Run SemVer checks in CI, catching breaking changes in PRs before they merge.

• Intentional API design: Declare which dependencies are implementation details, catching accidental leakage at compile time.

Design axioms

• Accuracy over approximation. Dependency information must reflect what actually ships. An SBOM with phantom dependencies is worse than none.

• Integrate into existing workflows. These capabilities should feel like natural extensions of commands developers already run.

• Explicit over implicit. Whether a dependency is public or private should be a deliberate choice in Cargo.toml.

• Incremental value. Each piece delivers value independently. SBOMs are useful without SemVer checks; SemVer checks are useful without pub/priv dependencies.

2026 goals

Goal	Point of contact	Task Owners and Champions
Continue resolving cargo-semver-checks blockers for merging into cargo	Predrag Gruevski	Ed Page (cargo), Alona Enraght-Moony (rustdoc)
Stabilize public/private dependencies
Stabilize Cargo SBOM precursor

Frequently asked questions

How do these goals relate to each other?

The three goals address different aspects of supply chain security and can proceed in parallel:

• Public/private dependencies helps control API surface by marking which dependencies should be exposed.

• cargo-semver-checks verifies no accidental breaking changes before publishing.

• Cargo SBOM generates accurate dependency manifests for compliance and security.

While independent, they’re complementary: knowing which dependencies are public helps SemVer checking focus on the right API surface.

Will cargo-semver-checks catch all breaking changes?

No tool can catch every possible breaking change, but it catches the most common categories (removed items, changed signatures, tightened bounds). The long-term goal is reliability sufficient for cargo publish to require compliance by default, with an escape hatch for intentional exceptions. In 2026, work focuses on resolving key blockers like type-checking lints and cross-crate analysis.

Why does Cargo need its own SBOM feature?

Third-party tools that generate SBOMs from cargo metadata see the full dependency graph across all configurations, not what actually gets compiled. Only Cargo knows which crates are selected after feature unification and target filtering.

Unblocking dormant traits

Summary

Long-blocked type system improvements finally ship, enabling extern types, scalable vectors, and painless trait refactoring.

Motivation

The status quo

Rust’s trait system is one of its most powerful features, but a number of long-desired improvements have been blocked on foundational work in the trait solver—the compiler component responsible for proving trait bounds, normalizing associated types, and more.

The current trait solver has accumulated technical debt and limitations over the years. This has led to:

• Known soundness bugs that can’t be fixed without breaking the solver’s assumptions (tracking board)
• Blocked language features like coinductive trait semantics, perfect derive, and better handling of higher-ranked types
• An inability to express new concepts in the type system, such as a richer Sized hierarchy needed for extern types or scalable vectors

The next-generation trait solver has been in development since late 2022 and is already stable for coherence checking (since Rust 1.84). Stabilizing it everywhere will fix these soundness issues, unblock the stalled features, and provide a foundation for future type system work.

With that foundation in place, we can:

• Extend the Sized hierarchy (RFC #3729, RFC #3838) to express types that are neither Sized nor ?Sized—like extern types (RFC #1861, no size at all) or scalable vectors (size known at runtime but not compile time)
• Enable backward-compatible trait refactoring so library authors can split traits into smaller pieces without breaking downstream code

RFC #1861: https://rust-lang.github.io/rfcs/1861-extern-types.html RFC #3729: https://rust-lang.github.io/rfcs/3729-sized-hierarchy.html RFC #3838: https://github.com/rust-lang/rfcs/pull/3838

What we are shooting for

By the end of 2026:

• New trait solver on stable. The next-generation trait solver replaces the old implementation everywhere, fixing known soundness bugs and providing a foundation for future type system work.
• Extern types work. You can declare extern type Foo; and use it in FFI code without the compiler demanding a size it can’t know.
• Trait evolution is field-testing on nightly. Library authors can experiment with splitting traits into smaller pieces without breaking downstream code, with the standard library running field trials.
• Scalable vectors are experimenting on nightly. Developers targeting AArch64 SVE can use scalable vector types that adapt to hardware capabilities.

Key use cases

• Soundness without surprises: Known trait solver bugs are fixed. Code that compiles continues to compile, except where it was relying on unsound behavior.

• C library bindings: FFI wrappers for C libraries with opaque types (like FILE *) can express that these types exist but have no meaningful size in Rust.

• Standard library evolution: The standard library team can begin field-testing trait refactoring—extracting common functionality into supertraits or reorganizing hierarchies—with the supertrait auto-impl feature, paving the way for ecosystem-wide adoption.

• High-performance SIMD: Performance-critical code for AArch64 servers can experiment with scalable vector extensions that adapt to hardware vector width.

Design axioms

• Fix the foundations first. Many desired features share common blockers in the trait solver. Rather than working around limitations repeatedly, we invest in fixing the underlying infrastructure once.

• Unblock, then polish. Ship the core capabilities that unblock use cases, even if ergonomic improvements come later.

• Preserve the ecosystem. Backward compatibility is paramount. Soundness fixes must not break working code except where that code relies on unsound behavior.

2026 goals

Frequently asked questions

How do these goals relate to each other?

The goals form a foundation-and-application pattern:

• Next-generation trait solver is the foundational layer. The new solver fixes soundness issues and provides the infrastructure needed for more sophisticated type system features.

• Sized hierarchy and scalable vectors extends the type system to express new categories of types, building on the sound foundation the new solver provides.

• Supertrait item implementations enables backward-compatible trait evolution—largely independent of the solver work, but benefits from landing after the new solver is stable.

Will these changes break my code?

The goal is to avoid breakage. The next-generation trait solver has been extensively tested via crater runs, and known regressions are either fixed or were cases where the old solver was unsound. The Sized hierarchy is additive—existing code using Sized and ?Sized continues to work. Supertrait item implementations is specifically designed to make changes that would have been breaking become non-breaking.

Expanding a-mir-formality to work better as a Rust type system spec

Summary

The goal here is to begin to move a-mir-formality into a position where it can be used as a formal specification of the Rust type system:

• Identify type system areas lacking in a-mir-formality
• Build a “roadmap” to add those lacking areas
• Continuing to contribute to a-mir-formality and build towards completeness
• Experiment with integration of a-mir-formality into an experimental reference

Motivation

The status quo

Most communication and definition of Rust’s type/trait system today takes place through informal argument and with reference to compiler internals. a-mir-formality offers a model of Rust at a much higher level, but it remains very incomplete compared to Rust.

Previously, there has been some progress in increasing contributions to a-mir-formality by others besides Niko Matsakis, but we still haven’t achieved a “fully living” project. That being said, steady progress has been and continues to be made, and we are at a point where it makes sense to try to outline a concrete plan for the future.

What we propose to do about it

The work here is primarily divided into two main goals:

1. Document the status of a-mir-formality implementation, identify a plan towards “completion”, and work towards that.
2. Experiment with integration of a-mir-formality into an “experimental reference” (led primarily as a separate goal).

For the former, it is expected this will intersect with other ongoing work (such as implementing borrow checking in a-mir-formality). It is also likely that this will be done through some combination of manual identification (such as through census of open issues) and more automatic identification (such as cross-testing the rustc test suite).

For the latter, it is not yet clear in what form the integration with the reference will occur. Possibilities may range from simple linking of behavior from the reference to the relevant rules in a-mir-formality, to more complex integration, such as embedding of a-mir-formality tests or rules within the reference itself. Notably, the goal is to allow the reference to remain a user-friendly text while providing a platform to share the more concrete formalism of the type system.

The types team has also discussed forming a subteam focused on a-mir-formality, which would likely own this work, rather than being owned primarily by individuals on the types team.

Team asks

Frequently asked questions

Does this cover XYZ work in a-mir-formality?

Generally, the work under the first subgoal can be thought of as the “meta” work that may be covered under other goals. The hope is that this goal should be mainly focused on the planning and organization around “finishing” the implementation of a-mir-formality to be a “complete” definition of the Rust type system, and that may include discussions about other ongoing work.

Is there an expectation that the integration of a-mir-formality into the reference must eventually be merged into the main reference?

Generally, no. The goal of the proposed work is not necessarily to find some single solution to integrate a-mir-formality into the reference, but rather to learn more about how this integration could happen, and moreso to inform us about how we can document the Rust type system in the reference in the best way possible to maintain preciseness with the constraint of user-friendly text.

Box notation for dyn async trait

Summary

Introduce .box notation and use it to enable dyn dispatch for traits with async methods. The initial scope is foo.method().box where method() returns a dyn-compatible RPITIT. In the future .box could be used more generally but before expanding it we would like to see progress on the work towards in-place initialization.

Contingent on contributor: Niko Matsakis is able to devote 1h/wk to support an experienced contributor or a cohort of contributors in driving this design forward as a lang experiment. This is a challenging problem that will require modifying various parts of the compiler and would also benefit from modeling in a-mir-formality.

Motivation

The status quo

Async fn in traits (AFIT) has been stable since Rust 1.75, but traits with async methods are not dyn-compatible. If you write:

#![allow(unused)]
fn main() {
trait HttpClient {
    async fn fetch(&self, url: &str) -> Response;
}
}

You cannot use &dyn HttpClient. The compiler rejects it because async methods return opaque future types whose size isn’t known at compile time, and dyn dispatch requires the caller to allocate space for the return value without knowing the concrete type.

Today, developers work around this by:

• Using static dispatch only: Generics everywhere, increasing compile times and binary size
• Manual desugaring: Write -> Pin<Box<dyn Future<Output = Response> + Send + '_>> and lose the ergonomics of async fn
• Proc macros: Use crates like async-trait or dynosaur that transform your code

The broader problem is complex

Making dyn Trait work with unsized return types is a deep problem that has been explored extensively. The caller must provide storage for the returned value, but doesn’t know its size. There are many options one might wish to use, with stack allocation and boxing being the most obvious. The in-place initialization goal is exploring the design space here for a fully general solution that allows the caller to have total control. But that design work requires time, and the goal for 2026 is only to settle on a specific design, not necessarily to implement it or even stabilize it! In the meantime, Rust’s support for async-fn-in-trait is only usable in narrow circumstances.

Boxing is the simplest approach and it’s what many users will want

The widespread use of the async-trait crate demonstrates that boxing is perfectly acceptable for many applications. async-trait transforms async fn into a fn that returns Pin<Box<dyn Future + Send>>, allocating on every call. Despite this cost, the crate has been downloaded millions of times because for most server and application code, the allocation overhead is negligible compared to the I/O being performed.

The problem with async-trait isn’t that it boxes. It’s that it modifies the trait definition, forcing all implementors to box on every call. This means library authors can’t use it for public traits where some users need static dispatch (no allocation) while others want dyn dispatch.

What we want is for the call site to decide whether to box. A library like Tower could define its Service trait using native async fn, implementors would write normal async code without any boxing, and generic code using T: Service would have zero allocation overhead. But users who need dyn Service could opt into boxing at the call site. Once the in-place initialization work proceeds, that same trait would support other allocation strategies too. But boxing unblocks the ecosystem now.

What we propose to do about it

The .box operator. We propose to build out an end-to-end solution based on the .box operator. The biggest impact on users is that they could invoke async fn via dyn trait, but they have to use .box at the call site, like so:

#![allow(unused)]
fn main() {
async fn fetch_data(client: &dyn HttpClient) -> Response {
    client.fetch(url).box.await
    //                ---
    //
    // Signals that the resulting future will be boxed.
}
}

For the purposes of this goal, .box would only be usable when calling a trait method where the trait definition returns -> impl SomeTrait. We expect it would be generalized in the future to serve as a replacement for Box::new but the details of that will depend on the outcome from the in-place initialization exploration currently taking place.

Method-scope dyn compatibility. An implication of the .box design is that we need to make the definition of dyn-compatibility more fine-grained. Today, a trait is only “dyn compatible” if all of its methods are dyn-safe – that is, can be used in the same way whether through dyn or not. But async fn (and -> impl Trait methods in general) are not dyn-safe in this way: they can only be used if the user specifies a memory allocation strategy (with .box being the first example).

For more details and a broader look, see the box, box, box blog post.

Work items over the next year

Task	Owner(s)	Notes
RFC for method-scope dyn compat	Niko Matsakis
RFC for .box notation	Niko Matsakis	Scoped to RPITIT/async returns initially
Implementation		Nightly experiment
Documentation

Team asks

Frequently asked questions

Why .box instead of implicit boxing?

Explicit is better here. Boxing has runtime cost (allocation), and Rust’s philosophy is to make costs visible. .box lets you see exactly where allocations happen, which matters for performance-sensitive async code.

What about the other allocation strategies?

The status quo section describes several options: boxing, in-place initialization, inline storage, and custom allocators. This goal focuses on boxing because it’s the option we’re most confident about. It’s proven by async-trait, works everywhere with an allocator, and is simplest to implement.

Other strategies can be added later with different syntax. For example, inline storage might use .inline::<N> or similar. The key insight is that we don’t need to solve everything at once.

Could .box generalize beyond async?

Yes. The notation could potentially work anywhere you would use Box::new, but we don’t want to figure out the full desugaring yet. This goal scopes .box to method call position (foo.bar().box) for RPITIT methods. That includes async fn, explicit -> impl Future, but also -> impl Iterator and similar patterns.

Why not just use the dynosaur crate?

The dynosaur crate is a good workaround, but native language support would:

• Avoid proc macro complexity and compile-time overhead
• Provide better error messages
• Enable optimizations the compiler can’t do through macro-generated code
• Make the pattern discoverable and standard

How does this relate to the “Just add async” roadmap?

Dynamic dispatch is a core Rust pattern. In sync code, you can freely use &dyn Trait for most traits. The “Just add async” theme is about making async code work like sync code. With .box, you can use &dyn Trait with async methods. You just need to explicitly box the future, which is a reasonable cost for the flexibility of dynamic dispatch.

Arbitrary Self Types

Summary

It is possible to create custom smart pointers by implementing the Deref trait. However, the standard library types are able to do things user-defined pointers can’t. For example, acting as a method receiver (self etc.) or turning a concrete type implementing a custom Trait to a dyn Trait.

These limitations are of particular importance to low-level systems (e.g. Rust for Linux) and cross-language interoperability (e.g. when designing a reference to C++ objects).

We want to stabilize these features to reduce the gap between smart pointers in the standard library and user-defined ones.

These features are all interconnected and depend on one another so we’re proposing a single goal that makes user-defined smart pointers on par with the ones in the standard library.

Motivation

The status quo

There are two main limitations custom pointers face today.

First, being able to use one as a method receiver. You can implement a method on a type with the first parameter being Box<self>, Rc<self>, or Arc<self> etc. and then call the method directly on the pointer.

The arbitrary_self_types language feature allows users to do the same for their pointers:

#![allow(unused)]
fn main() {
pub struct SmartPointer<T> { ... }

impl<T> Receiver for SmartPointer<T> {
    type Target = T;
}

struct Person { ... };

// It is now possible to use `SmartPointer`s as method receivers.
// Previously, only blessed types like `Box` could act like method receivers.
impl Person {
    pub fn biometrics(self: &SmartPointer<Self>) -> &Biometrics {
        ...
    }
}

let person: SmartPointer<Person> = get_data();
// Method calls can now also dispatch `SmartPointer<Person>` to the intended methods.
let _: &Biometrics = person.biometrics();
}

Arbitrary self types do this by implementing the Receiver trait. Right now, we have a blanket Receiver implementation for any type that implements Deref.

We want to remove that coupling and have Receiver be a standalone trait. In particular, we would like to keep the door open for the ability to have Receiver::Target and Deref::Target different (when both are implemented) in the future.

The second limitation is around coercion to a dyn Trait. We want to be able to define custom smart pointers that work with trait objects.

It would allow us to do this:

#[derive(CoercePointee)]
#[repr(transparent)]
pub struct SmartPointer<T> { ... }

impl<T: ?Sized> Deref for SmartPointer<T> {
    type Target = T;
    fn deref(&self) -> &T {
        &self.0
    }
}

trait MyTrait {}

impl MyTrait for i32 {}

fn main() {
    let ptr: MySmartPointer<i32> = MySmartPointer(Box::new(42));

    // This coercion would be an error without the derive.
    let ptr: MySmartPointer<dyn MyTrait> = ptr;
}

What we propose to do about it

For arbitrary_self_types:

• Implement the decoupling of the two traits.
• Decide on the fate of the arbitrary_self_types_pointers feature, whose design would run against common language principles and may hinder future library and language feature evolution.
• Update the Rust language reference to codify the method resolution rules while considering possible language extensions from “Beyond &.”
• Propose a second stabilisation attempt to conclude the project goal work.

For Deref/Receiver chain:

While we have settled with splitting the coupling of the two traits so that they will affect method resolution independently, we would also like to open a small language experiment by introducing a feature gate arbitrary_self_types_split_chain, through which the Rust language users can experiment with diverging target types in Receiver and Deref. Through this experiment, we will collect the data on the utility of having this feature in the language and potential use cases of this construction.

• Land the implementation for decoupling the Deref and Receiver traits rust#146095 at the start of the language experiment.
• Engage the community through various channels and users that have interest in or make use of the Receiver language feature to collect opinions, when they find a need to enable this new unstable feature.
• Draft a stabilisation or de-RFC report based on the experiment data to finalise the fate of this unstable feature.

For derive(CoercePointee):

The implementation is largely done, but the stabilization is blocked on arbitrary_self_types. Once that feature is stabilized, we can proceed with stabilizing derive(CoercePointee) too.

Work items over the next year

Team asks

Frequently asked questions

What do I do with this space?

This is a good place to elaborate on your reasoning above – for example, why did you put the design axioms in the order that you did? It’s also a good place to put the answers to any questions that come up during discussion. The expectation is that this FAQ section will grow as the goal is discussed and eventually should contain a complete summary of the points raised along the way.

asm_const_ptr

Summary

Short description of what you will do over the next year.

Motivation

The status quo

Elaborate in more detail about the problem you are trying to solve. This section is making the case for why this particular problem is worth prioritizing with project bandwidth. A strong status quo section will (a) identify the target audience and (b) give specifics about the problems they are facing today. Sometimes it may be useful to start sketching out how you think those problems will be addressed by your change, as well, though it’s not necessary.

What we propose to do about it

Explain your overall approach to solving the problem. Explain your design philosophy (including design axioms). Focus your discussion on what you aim to get done this year, but it is good to also give a sense for the “overall goal” you are working towards, if it extends beyond the work for this year. Team(s) should give you feedback on whether they are aligned both with your short-term and longer-term goals.

Work items over the next year

Team asks

Assumptions on Binders

Summary

Attempt to implement a version of -Zhigher-ranked-assumptions which works for all binders, not just witness types of futures.

Motivation

The status quo

Binders (for<'a>) currently don’t track any where clauses involving the bound variables introduced. This leads to many bugs (some soundness bugs) e.g. “that async Send bug” (#149407), or higher ranked subtyping being unsound (#25860).

The -Zhigher-ranked-assumptions flag currently exists and tries so solve some of the problems caused by this, but it is not fully general and likely not the implementation strategy we want when solving all problems in this area.

What we propose to do about it

Figure out a different impl strategy than -Zhigher-ranked-assumptions’s current design then try and implement a prototype.

Work items over the next year

Team asks

Frequently asked questions

Will anything be stabilized

We are not intending to do anything affecting stable users in this goal period. It will likely take a while to get anything working, let alone good enough to stabilize.

Async Future Memory Optimisation

Summary

We want to solve async-future memory bloat problem.

Playground

async fn combining_future(compute: impl Future<Output = ()>) {
    async {}.await;
    compute.await;
}

fn main() {
    let blob = [0u8; 65536];
    let monster = combining_future(combining_future(combining_future(combining_future(async move {
        async {}.await;
        println!("{:?}", blob)
    }))));
    println!("{}", std::mem::size_of_val(&monster));
    //~^ prints at least 1000000 bytes
}

We would like to deliver the first async-future memory packing scheme -Zpack-coroutine-layout as a nightly-only compiler flag, followed by a more aggressive memory packing scheme built on top of the foundation of the first pack-coroutine-layout support. Meanwhile, we would like to conduct two experiments in two possible approaches that could further improve the memory economy of async-futures.

• Explore the memory layout optimisation by enabling coroutine state inlining.
• Explore direct lowering of Rust async-futures, and coroutines in particular, into native LLVM coroutine intrinsics.

Motivation

The status quo

Exponential growth of async-future types has been a long-standing issue, tracked by #62958. In addition, any data that is alive and used across more than two await points will incur further penalty, because their memory slots are indiscriminately reserved throughout the futures’ life span.

This issue has manifested in two ways that hinder the adoption of general async Rust or require use of unergonomic mitigations.

• On cloud platforms and in general network computing applications, it has led to unexpected or even unexplainable stack-overflow that is hard to debug. Application developers have to resort to unnecessary heap allocation and indirection in order to restore reliability.
• On embedded platforms and specialised environments, such as Linux Kernel, this issue has been quoted as the greatest concern to respective developers. Rust async has been a very attractive abstraction, but the memory footprint issue has deterred adoption in such fields because the memory requirement is more stringent.

What we propose to do about it

A proposed fix has been proposed in #135527 which strives for perfect preservation of coroutine semantics while reducing the memory bloat contributed by coroutine captures, which has been the most common case for large future sizes. This experimental implementation work has shown success in improving future sizes. It also retains the default memory layout scheme in order to allow experimentation without affecting existing stable Rust users. Based on this foundation, the proposed work involves a second packing scheme to relax the overall layout computation, so that memory allocation can still be released even values are live across more than one await suspension points, enabling even further memory compaction. These changes will continue to abide by the design axiom, under which the surface Rust language remains unchanged and improvement work should be contained only in the internal Application Binary Interface (ABI) or code generation.

The proposed work also includes two further experiments as stretch goals.

• Enabling inlining of coroutine states: Many cases of bloat in async-future arise from combining futures in a nested fashion, where one future needs to drive other futures towards completion. The state and data of the nested futures are currently opaque to the driver future and the layout calculation must consider the memory layouts of the futures in isolation. This unfortunately leads to sub-optimal memory allotment leaving padding gaps that could have been used. Inlining these futures under reasonable conditions, on the other hand, allows the layout computation to pool the liveness information of futures’ internal data as a whole and enable the opportunity to fill the padding gaps.
• Experimenting with unstable coroutine intrinsics of LLVM: LLVM has since made coroutine intrinsics available, albeit without stability guarantee across releases at the moment. Nevertheless, this enables a code generation strategy for Rust async futures, which is to directly lower coroutine MIRs into LLVM IR coroutines, through one or more lowering strategies from LLVM. This allows LLVM to independently compute coroutine liveness information and eventually layout information directly, like how regular Rust synchronous fn is compiled, by exploiting the target information known to LLVM. This will potentially also allow LLVM to further apply optimisation to the final coroutine code, given more accurate information made available by the Rust code generator.

Work items over the next year

Team asks

Frequently asked questions

Async statemachine optimisation

Summary

Add optimisations to the coroutine MIR transform to elide or simplify the generated statemachines.

This will help both async futures and generators.

Note: This has some overlap with this other proposal. I’m not trying to userp the issue. I was working on it incidentally at the same time and noticed very late that proposal already existed.

Motivation

The status quo

Generated Rust futures (from async blocks and functions) are unoptimised. That is, they always naively generate a full statemachine even when it’s not required.

Often on opt-level 3, the compiler is able to optimize out this statemachine. But when the tree of futures gets deep, this is no longer the case. The compiler struggles even more on opt-level s or z where even simple cases aren’t optimized away.

Every statemachine also has a panicking branch. This litters the code with panics that makes the compiler’s job a lot more difficult. Those panics will also pretty much never be run when a good functioning executor is used to poll the futures.

What we propose to do about it

I want to come up with a list of optimisations we can do. I’ve already thought of a couple.

A simple example:

#![allow(unused)]
fn main() {
// MIR for `foo::{closure#0}` 0 coroutine_resume
/* coroutine_layout = CoroutineLayout {
    field_tys: {},
    variant_fields: {
        Unresumed(0): [],
        Returned (1): [],
        Panicked (2): [],
    },
    storage_conflicts: BitMatrix(0x0) {},
} */

async fn foo() -> i32 {
    5
}
}

This generates a whole statemachine with 3 states. In the best case, LLVM can optimize this away. But when this is deep in an async ‘tree’, the compiler can fail to optimize this away. This leads to lost performance and binary size bloat. The latter of which is very noticeable on embedded.

Another example:

#![allow(unused)]
fn main() {
async fn bar() -> i32 {
    foo().await
}
}

Here bar gets its own future, just to poll the foo future. Instead bar could ‘become’ the foo future which would save a statemachine.

I believe that if we keep stacking optimizations like these, we’ll get some really nice results.

I’ve got 3 optimisations on my list so far. You can see them in the work items and in the draft blog post I’m writing (linked in FAQ).

Work items over the next year

Team asks

Frequently asked questions

Why this, why now?

I work as an embedded developer most of the time. We love to use async Rust, but as the firmware grows in size, the async bloat gets quite unwieldy. For example, I developed a, async radio device driver. After I was done I wrote an example for it.

The example was about 35 KB in binary size. This seemed way too big, so I converted it to be mostly blocking code and the size dropped to about 17 KB. This shows how much bloat async can add.

For a big customer we were running against the 900 KB limit of the hardware and had to do a lot of manual optimisations to the async code to make it fit. I then looked into the MIR pass responsible and found it pretty much does no optimisations.

The plan is/was to find parties willing to fund work on these optimisations. To get to stage, we want to release 2 blogposts on the Tweede golf website. The first one will cover the bloat and some optimisations you can do as a developer now and the second one (draft) dives more into how we could bring those optimisations to the compiler so you don’t have to apply them manually anymore.

What’s your commitment?

Without funding other commercial work will sadly take priority. This means I can only commit up to half a day per week on most weeks.

With funding we can make it a real project and we (Tweede golf) can bring in more people too like Folkert de Vries and/or bjorn3.

How does this relate to the other similar proposal?

We have similar goals, but a different philosofy.

I want to tackle the problem at the front:

• Stop generating statemachines that don’t have to be there
• Make the compiler’s job easier by removing panic paths and branches
• Make statemachines smaller

The other proposal tackles the problem at the back:

• Given there are statemachines, make them interact better with each other (real proper inlining)
• Research the options LLVM now provides

I think these can compliment each other. Optimisations done at the front will trickle down to the optimisations at the back. Inlining a small statemachine should prove easier/more efficient than inlining a big statemachine.

Also, for code size you may not want to inline everything, just as with normal blocking code.

BorrowSanitizer

Summary

We are building BorrowSanitizer: an LLVM-based instrumentation tool for finding violations of Rust’s aliasing model. In 2026, we want to make it feature-complete and useful in practice.

Motivation

The status quo

Developers rely on Miri to validate their programs against Rust’s latest Tree Borrows aliasing model. However, Miri cannot find these Rust-specific aliasing bugs when they are caused by foreign function calls. Miri’s performance is also several orders of magnitude slower than native execution. As Rust is increasingly being in security-critical C and C++ applications, like Android and Chromium, developers will need a method for finding aliasing errors that can scale across language boundaries.

What we propose to do about it

We are developing BorrowSanitizer to fix this tooling gap. Much like AddressSanitizer, MemorySanitizer, and other LLVM-based tools, BorrowSanitizer inserts checks during compilation to detect errors at run-time. Its purpose is to find violations of Rust’s newest Tree Borrows aliasing model, as well as accesses out-of-bounds and use-after-free errors.

BorrowSanitizer relies on changes to the Rust compiler, an LLVM instrumentation pass, and a runtime library. We modified the compiler to emit special “retag” intrinsics that indicate when references are created and updated. Our LLVM pass lowers these intrinsics into runtime calls that associate each pointer with “provenance” metadata (see RFC #3559(https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html)). We validate provenance before memory accesses to detect undefined behavior.

Our primary goal is for BorrowSanitizer to be useful in practice. This will require broad support for Rust, C, and C++ language features. We want to achieve better performance than Miri while fully supporting the different features of Tree Borrows.

Work items over the next year

Throughout 2026, we will complete the remaining features needed for BorrowSanitizer to have parity with Miri for detecting aliasing violations. We will finish contributing the retag intrinsics described in our previous project goal and evaluate when and how the rest of BorrowSanitizer should be integrated with the compiler.

One topic for discussion is whether the BorrowSanitizer itself should live in a subtree of rust-lang/rust, with a new Github repo under rust-lang, or as an independent project.

BorrowSanitizer is open source and available on GitHub, and we welcome any contributions. We will post monthly status updates on our website throughout 2026. We are available at any point for Q/A on Zulip. Ian McCormack will be the primary point-of-contact for the BorrowSanitizer Team.

Team asks

Frequently asked questions

build-std

Summary

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

Motivation

build-std is a well-known unstable feature in Cargo which enables Cargo to re-build the standard library, this is useful for a variety of reasons:

1. Building the standard library without relying on unstable escape hatches

2. Building standard library crates that are not shipped for a target

3. Using the standard library with tier three targets

4. Unblock stabilisation of ABI-modifying compiler flags

5. Re-building the standard library with different codegen flags or profile

The following use cases are not currently planned as part of this project goal, but could be supported with follow-up goals:

1. Using the standard library with custom targets

2. Enabling Cargo features for the standard library

3. Progress towards using miri on a stable toolchain

Some use cases are unlikely to be supported by this project goal unless a new and compelling use-case is presented, and so this project goal may make decisions which make these motivations harder to solve in future:

1. Modifying the source code of the standard library

2. Retire the concept of the sysroot

These features are more useful for some subsets of the Rust community, such as embedded developers where optimising for size can be more important and where the targets often don’t ship with a pre-compiled std.

The status quo

In previous goal cycles, the goal authors in collaboration with relevant project teams have drafted a proposed design for build-std, resulting in rust-lang/rfcs#3873, rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and two yet-to-be-published RFCs. rust-lang/rfcs#3873 has since been accepted.

What we propose to do about it

There are two primary objectives of this goal in this next goal cycle:

1. Continue to address feedback on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 until these RFCs are accepted

2. Start implementation of rust-lang/rfcs#3874 and rust-lang/rfcs#3875

Work items over the next year

Team asks

Frequently asked questions

None yet.

rust-lang/rfcs#3874: https://github.com/rust-lang/rfcs/pull/3874 rust-lang/rfcs#3875: https://github.com/rust-lang/rfcs/pull/3875

Cargo cross workspace cache

Summary

Work towards a build cache that is shared across workspaces to build times and reduce disk usage.

Motivation

The status quo

Currently Cargo stores build artifacts in build-dir (which defaults to target in root of the workspace). These artifacts are local to the current workspace. This is not ideal as it requires Cargo to rebuild build units when we could simply reuse the artifacts that have previously been built for other workspaces. Not sharing artifacts across workspaces also results in higher disc usage as files are duplicated.

What we propose to do about it

In 2025, we split target-dir into 2 directories (artifact-dir and build-dir) as well as began re-organizing the file layout to be grouped by build unit. With this preliminary work complete, we can begin working towards creating a shared cache that shares build units across workspaces.

A shared cache would:

• Skip compilation for commonly used crates
• Reduce disk usage as we only store build artifacts for a given build unit once
• Make it possible to share build artifacts between profiles (e.g. debug, release)
• Provide a central location to cleanup unneeded build artifacts (potentially automatically by Cargo)
• Could be extended in the future to be pre-populated from a remote cache for CI usecases.

In 2026, we will design and implement this cache in Cargo, making it available on nightly for users to begin experimenting with. (tracked in cargo#5931) As part of implementing the cache we will stabilize the build-dir layout rework that was done in 2025. In the beginning, the cache would be fairly conservative in what is cached but would be expanded over time. At the end of the year, we should have an understanding of the benefits and tradeoffs of the design we pick as well as a rough path towards stablization.

Work items over the next year

Team asks

Frequently asked questions

What about shared CARGO_TARGET_DIR?

Having a global CARGO_TARGET_DIR is a common pattern, but comes with some downsides like cargo clean removing all artifacts for all workspaces as well not having the output binaries in the workspace directory. Users also need to be aware of this pattern and configure it themselves. It would be great if we could get the benefits of a shared CARGO_TARGET_DIR out of the box no configuration.

What about tools like sccache?

Tools like sccache try to infer inputs for hashing a cache key from command-line arguments. In Cargo, we have much more knowledge about the dependency graph and crate metadata, which could allow us to be more aggressive in what we choose to cache.

Prototype a new set of Cargo “plumbing” commands

Summary

1. Refactor Cargo to allow hacks in proposed cargo-plumbing commands to be removed (cargo-plumbing#82).
2. Round out proposed commands (issues)
3. Finalize the message formats (cargo-plumbing#18)

Contingent on contributor: This goal needs contributors to refactor Cargo internals, implement remaining plumbing commands, optimize performance, and iterate on output schemas. The work is primarily in rust-lang/cargo and crate-ci/cargo-plumbing. Estimated time commitment: TBD.

Motivation

Cargo is a “porcelain” (UX) focused command and is highly opinionated which can work well for common cases. However, as Cargo scales into larger applications, users need the ability to adapt Cargo to their specific processes and needs.

The status quo

While most Cargo commands can be used programmatically, they still only operate at the porcelain level. Currently, Cargo’s plumbing commands are

• cargo read-manifest:
  • works off of a Cargo.toml file on disk
  • uses a custom json schema
  • deprecated
• cargo locate-project:
  • works off of a Cargo.toml file on disk
  • text or json output, undocumented json schema
  • uses a pre-1.0 term for package
• cargo metadata:
  • works off of Cargo.toml, Cargo.lock files on disk
  • uses a custom json schema
  • can include dependency resolution but excludes feature resolution
  • some users want this faster
  • some users want this to report more information
  • See also open issues
• cargo pkgid:
  • works off of Cargo.toml, Cargo.lock files on disk
  • text output
• cargo verify-project:
  • works off of a Cargo.toml file on disk
  • uses a custom json schema
  • uses a pre-1.0 term for package
  • deprecated

There have been experiments for a plumbing for builds

• --build-plan attempts to report what commands will be run so external build tools can manage them.
  • The actual commands to be run is dynamic, based on the output of build scripts from build graph dependencies
  • Difficulty in supporting build pipelining
• --unit-graph reports the graph the build operates off of which corresponds to calls to the compiler and build scripts
  • Also provides a way to get the results of feature resolution

Thanks to GSoC, we now have prototypes for some plumbing commands.

The next 6 months

Continue on the third-party subcommand to experiment with plumbing commands (source).

Task	Owner(s) or team(s)	Notes
Refactor cargo
Implement remaining commands
Inside Rust blog post inviting feedback	Ed Page
Optimizing Cargo	, Ed Page
Iterate on schemas including schema evolution plan

See 2025h2 goal for more background.

The “shiny future” we are working towards

• Collect user feedback on these commands and iterate on them for eventual inclusion into Cargo
• Evaluate refactoring Cargo to better align with these plumbing commands to have better boundaries between subsystems
• Evaluate splitting the cargo [lib] into crates for each of these plumbing commands as smaller, more approachable, more “blessed” Rust APIs for users to call into

Team asks

Frequently asked questions

Stabilize cargo-script

Summary

Stabilize support for “cargo script”, the ability to have a single file that contains both Rust code and a Cargo.toml.

Motivation

Being able to have a Cargo package in a single file can reduce friction in development and communication, improving bug reports, educational material, prototyping, and development of small utilities.

The status quo

Today, at minimum a Cargo package is at least two files (Cargo.toml and either main.rs or lib.rs). The Cargo.toml has several required fields.

To share this in a bug report, people resort to

• Creating a repo and sharing it
• A shell script that cats out to multiple files
• Manually specifying each file
• Under-specifying the reproduction case (likely the most common due to being the easiest)

To create a utility, a developer will need to run cargo new, update the Cargo.toml and main.rs, and decide on a strategy to run this (e.g. a shell script in the path that calls cargo run --manifest-path ...).

Cargo has had unstable Cargo script support for years. New, unstable syntax has been added and gone through rounds of testing. A stabilization report exists for frontmatter syntax but work is needed to finish going through that process and then on Cargo’s side.

The next 6 months

Work with T-lang, T-cargo, and other affected teams as we go through the stabilization process.

The “shiny future” we are working towards

Team asks

Frequently asked questions

Continue resolving cargo-semver-checks blockers for merging into cargo

Summary

Design and implement cargo-semver-checks functionality that lies on the critical path for merging the tool into cargo itself. Continues the work of the 2025h2 goal.

Motivation

Cargo assumes that all packages adhere to semantic versioning (SemVer). However, SemVer adherence is quite hard in practice: research shows that accidental SemVer violations are relatively common (lower-bound: in 3% of releases) and happen to Rustaceans of all skill levels. Given the significant complexity of the Rust SemVer rules, improvements here require better tooling.

cargo-semver-checks is a linter for semantic versioning (SemVer) in Rust. It is broadly adopted by the Rust community, and the cargo team has expressed interest in merging it into cargo itself as part of the existing cargo publish workflow. By default, cargo publish would require SemVer compliance, but offer a flag (analogous to the --allow-dirty flag for uncommitted changes) to override the SemVer check and proceed with publishing anyway.

The cargo team has identified a set of milestones and blockers that must be resolved before cargo-semver-checks can be integrated into the cargo publish workflow. Our goal here is to make steady progress toward resolving them.

From a user perspective, we want a fearless cargo update: one’s project should never be broken by updating dependences without changing major versions.

From a maintainer perspective, we want a fearless cargo publish: we want to prevent breakage, not to find out about it when a frustrated user opens a GitHub issue. Just like cargo flags uncommitted changes in the publish flow, it should also quickly and accurately flag breaking changes in non-major releases. Then the maintainer may choose to release a major version instead, or acknowledge and explicitly override the check to proceed with publishing as-is.

To accomplish this, cargo-semver-checks needs the ability to express more kinds of lints (including manifest and type-based ones), eliminate false-positives, and stabilize its public interfaces (e.g. the CLI). At that point, we’ll have lifted the main merge-blockers and we can consider making it a first-party component of cargo itself.

The status quo

cargo-semver-checks currently ships with 245 lints, and is effective at catching many forms of breakage — both in crate manifests and also inside crates’ source code.

However, many more lints remain to be written, and they will require additional infrastructure in both rustdoc JSON and in cargo-semver-checks itself, as we describe below.

For a detailed look at the status quo, we recommend checking out the most recent cargo-semver-checks annual summary

What we propose to do about it

The following are the largest remaining blockers for merging cargo-semver-checks in Cargo:

Performing type-checking in lints

https://github.com/obi1kenobi/cargo-semver-checks/issues/149

This lets us catch changes like: pub fn example(x: i64) {} becoming pub fn example(x: String) {}.

This is our most commonly requested feature today, and will resolve the largest remaining class of false-negative (lint should fire, but doesn’t) outcomes!

We plan to accomplish this in two steps:

• Expose additional information in rustdoc JSON to make it possible to reliably observe that something about a type has changed. This will enable some lints by itself, but is not sufficient in all cases: for example, changing impl Display to String or vice versa isn’t always breaking.
• Build out infrastructure in cargo-semver-checks to make it possible to generate “witness” programs: ones on which cargo check can be executed in order to determine whether a changed type caused breakage or not. This will allow us to rely on rustc to be the arbiter of breakage, instead of requiring us to reimplement the Rust type checker, trait solver, borrow checker, etc. Some of the infrastructure here was already built as part of GSoC 2025, and we expect to continue building on top of that foundation.

Linting across crate boundaries

https://github.com/obi1kenobi/cargo-semver-checks/issues/638

Linting across crate boundaries with high reliability and acceptable performance, so that for example, we can correctly handle cross-crate item re-exports. This will resolve the largest remaining class of false-positive bugs (a lint fires where it shouldn’t) in our linting system.

Completing this will require close cooperation with T-rustdoc, to enable rustdoc JSON files to be reliably connected to each other. This work already began in 2025 with Alona Enraght-Moony leading it from the rustdoc side.

Participate Google Summer of Code (GSoC)

The main blocker towards progress is funding and development capacity. cargo-semver-checks has successfully participated in GSoC before and we plan to do it again.

Work items over the next year

Owner: Predrag Gruevski, as maintainer of cargo-semver-checks

I (Predrag Gruevski) will be working on this effort. The only other resource request would be occasional discussions and moral support from the cargo and rustdoc teams, of which I already have the privilege as maintainer of a popular cargo plugin that makes extensive use of rustdoc JSON.

Team asks

Frequently asked questions

This section is unchanged from the 2024h2 goal.

Why not use semverver instead?

Semverver is a prior attempt at enforcing SemVer compliance, but has been deprecated and is no longer developed or maintained. It relied on compiler-internal APIs, which are much more unstable than rustdoc JSON and required much more maintenance to “keep the lights on.” This also meant that semverver required users to install a specific nightly versions that were known to be compatible with their version of semverver.

While cargo-semver-checks relies on rustdoc JSON which is also an unstable nightly-only interface, its changes are much less frequent and less severe. By using the Trustfall query engine, cargo-semver-checks can simultaneously support a range of rustdoc JSON formats (and therefore Rust versions) within the same tool. On the maintenance side, cargo-semver-checks lints are written in a declarative manner that is oblivious to the details of the underlying data format, and do not need to be updated when the rustdoc JSON format changes. This makes maintenance much easier: updating to a new rustdoc JSON format usually requires just a few lines of code, instead of “a few lines of code apiece in each of hundreds of lints.”

cfg(no_fp_fmt_parse)

Summary

Short description of what you will do over the next year.

Motivation

The status quo

Elaborate in more detail about the problem you are trying to solve. This section is making the case for why this particular problem is worth prioritizing with project bandwidth. A strong status quo section will (a) identify the target audience and (b) give specifics about the problems they are facing today. Sometimes it may be useful to start sketching out how you think those problems will be addressed by your change, as well, though it’s not necessary.

What we propose to do about it

Explain your overall approach to solving the problem. Explain your design philosophy (including design axioms). Focus your discussion on what you aim to get done this year, but it is good to also give a sense for the “overall goal” you are working towards, if it extends beyond the work for this year. Team(s) should give you feedback on whether they are aligned both with your short-term and longer-term goals.

Work items over the next year

Team asks

Const Generics

Summary

Extend const generics in two independent directions, both aiming for stabilization:

• adt_const_params: Allow structs and enums as const generic arguments, not just integers.
• min_generic_const_args: Allow associated constants as const generic arguments (e.g., Foo<T::ASSOC_CONST>).

We will also model const generics in a-mir-formality and experiment with upstreaming those changes into the Rust specification. This work also serves as a forcing function for advancing a-mir-formality and its integration into the Rust specification.

Motivation

The status quo

The min_const_generics feature is stable, but with significant limitations on what can be used as a const generic argument:

• Only integers: Const generic parameters are limited to integer types. You cannot use structs or enums, even simple ones like struct Dimensions { width: u32, height: u32 }.
• Only literals or generic parameters: You can write Foo<5> or Foo<N> (where N is a const generic parameter), but you cannot write Foo<T::ASSOC_CONST> to use an associated constant.

When using const generics it is common to run into these limitations and be unable to move forwards, having to rewrite your code to use workarounds or not use const generics at all. This is a poor user experience and makes the language feel incomplete.

The next few steps

We are extending const generics in two independent directions:

adt_const_params: Extending const generic arguments to include structs and enums. The implementation is largely complete, but we need to:

• Publish an RFC defining which ADTs are permitted. Some structs may be excluded due to concerns about privacy and unsafe invariants when the compiler infers const values. The RFC will nail down the precise rules.
• Model the feature in a-mir-formality to ensure we have a solid specification.

min_generic_const_args (MGCA): Extending const generic arguments to include associated constants. This is currently in a “full prototype” state (feature(min_generic_const_args) has been merged) with more work needed before stabilization.

The “shiny future” we are working towards

Our ultimate goal is to stabilize all parts of the const generics feature that were left out of the minimum stabilization. Users should not encounter “functionality cliffs” where const generics suddenly stops working as well as type generics, forcing code to be rewritten to work around language limitations.

Design axioms

TBD

Work items over the next year

Team asks

Frequently asked questions

What is the role of lang vs types team in the stabilizations?

The question of what equality means and what kinds of ADTs (structs, enums) can be used as const values, intersects both lang and types (adt_const_params).

Design and stabilization of min_generic_const_args is purely a types team affair.

Stabilize Const Traits

Summary

Finish drafting the const traits RFC to address outstanding concerns; do any remaining work necessary in the compiler to push const traits towards stabilization.

Motivation

const fn on stable are unable to invoke trait methods, limiting their usefulness. After years of experimentation, the compiler now has a promising implementation of const traits and key parts of the stdlib have been updated to use it. However, the feature is still firmly in experimental territory: there has never been an accepted RFC describing its syntax.

The goal for the next year is to build upon the currently open RFC to finalize the syntax and semantics of const traits, make the required compiler changes, issue a public call for experimentation, and otherwise pave the ground for stabilization.

The status quo

People write a lot of code that will be run in compile time. They include procedural macros, build scripts (42.8k hits on GitHub for build.rs), and const functions/consts (108k hits on GitHub for const fn). Not being able to write const functions with generic behavior is often cited as a pain point of Rust’s compile time capabilities. Because of the limited expressiveness of const fn, people may decide to move some compile time logic to a build script, which could increase build times, or simply choose not to do it in compile time (even though it would have helped runtime performance).

There are also language features that require the use of traits, such as iterating with for and handling errors with ?. Because the Iterator and Try traits currently cannot be used in constant contexts, people are unable to use ? to handle results, nor use iterators e.g. for x in 0..5.

What we propose to do about it

The compiler already has a mature implementation of const traits. We will draft the RFC to address any outstanding concerns from existing feedback. Afterwards we will call for testing and push for stabilization.

Work items over the next year

Team asks

Frequently asked questions

What do I do with this space?

This is a good place to elaborate on your reasoning above – for example, why did you put the design axioms in the order that you did? It’s also a good place to put the answers to any questions that come up during discussion. The expectation is that this FAQ section will grow as the goal is discussed and eventually should contain a complete summary of the points raised along the way.

Crate Slicing for Faster Fresh Builds

Summary

Prototype “crate slicing” — a static analysis technique that computes the transitive closure of items actually used from dependency crates and generates minimal sliced versions, reducing frontend parsing and type-checking overhead during fresh builds.

Motivation

The status quo

Rust compilation remains I/O and CPU-bound on dependency crates during fresh builds. Consider a typical async web service:

[dependencies]
tokio = { version = "1.48", features = ["full"] }
axum = "0.7"
serde = { version = "1", features = ["derive"] }
sqlx = { version = "0.8", features = ["postgres", "runtime-tokio"] }

This dependency graph expands to 161 crates. The tokio crate alone contains 315 module files totaling 92,790 lines of Rust source. Yet an application may only use a fraction of tokio’s public API surface (e.g., tokio::spawn)， and some may depend only on a subcrate e.g., tokio-macros rather than on the main crate (as did by the cargo-slicer tool).

The Rust compiler is designed to find and diagnose errors first and generate good code quickly second, hence it needs to do the following steps:

1. Parse all the ~90,000 lines
2. Resolve names and expand macros across all modules and submodules
3. Type-check all items, including unused ones
4. Monomorphize generic code (though only used instantiations)

Only step 4 naturally excludes unused code. Steps 1-3 process everything.

Current mitigations:

• Incremental compilation: Caches type-checking results but requires prior builds
• sccache: Caches compilation artifacts but requires cache hits
• Cranelift: Accelerates codegen but not frontend (steps 1-3)
• Parallel frontend: Parallelizes work but doesn’t reduce total work
• Hint mostly unused: Avoid codegen from unused dependencies by hinting on LLVM linker

None of these reduce the fundamental quantity of source code processed during fresh builds.

The next 6 months

We propose to slice crates: statically analyzing which items a project uses from each dependency and generating minimal crate versions containing only those items plus their transitive dependencies.

Technical approach:

1. Usage extraction: Parse project source using a customized parser or rust-analyzer to identify:

   • Direct type references, e.g., tokio::net::TcpListener
   • Use statements, e.g., use axum::{Router, routing::get}
   • Method calls via variable type tracking, e.g., listener.accept() → TcpListener::accept
   • Trait bounds, e.g., impl<T: Serialize> → serde::Serialize

2. Crate indexing: Build a dependency graph of all items in the target crate:

   • Map each pub item to its defining module
   • Track pub use re-exports through the module tree
   • Evaluate #[cfg(...)] expressions against enabled features
   • Handle #[path = "..."] module redirections

3. Transitive closure: Compute minimal item set:

   • Include all trait impls for used types
   • Follow type definitions for struct fields and enum variants
   • Expand pub use crate::* glob re-exports
   • Preserve visibility modifiers for cross-module access
   • Include document cooments and attributes related to the preserved items

4. Sliced crate generation: Emit minimal source:

   • Copy only needed module files
   • Filter items within each module
   • Generate Cargo.toml with subset of features/dependencies

5. Rustc verification: For the soundness and correctness with respect to type inferencing on trait bounds, e.g., simply slicing away everything unused may lead to errors unless we have considered the corner cases. To make sure it generates correct results, we will use Rust compiler to double check the decisions made at the testing phase, before release the solution as replacement of the Rust compiler.

Prototype results (December 2025):

We have an early implementation (cargo-slicer) just demonstrates feasibility on major ecosystem crates:

Measured slice times for smaller utility crates:

The prototype handles complex patterns:

• Feature flag evaluation: Parses #[cfg(all(feature = "std", not(feature = "parking_lot")))] expressions and evaluates against cargo metadata
• Facade crates: Handles futures (re-exports from futures-*) and sqlx (facade over sqlx-core)
• Platform-specific code: Filters #[cfg(unix)] / #[cfg(windows)] based on target
• Proc-macro crates: Preserves as external dependencies (not sliced)
• Re-export chains: Traces pub use self::module::Item through module hierarchy