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
build-std	David Wood	cargo
		compiler	n/a
		crates-io	n/a
		libs	n/a
Const Generics	Boxy	lang	Niko Matsakis
		types
		compiler	n/a
Stabilize Const Traits	Deadbeef	lang
		compiler	n/a
Field Projections	Benno Lossin	lang	Tyler Mandry
		compiler
		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
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
Stabilize the next-generation trait solver	lcnr	types	lcnr
		lang	Niko Matsakis
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
Stabilize Return Type Notation	Niko Matsakis	lang	Niko Matsakis
		types
Normative Documentation for Sound unsafe Rust	Pete LeVasseur	opsem	Ralf Jung
		lang-docs	n/a
		lang	n/a
		libs-api	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
Rust for Linux in stable: compiler features	Tomas Sedovic	compiler	Wesley Wiser
Rust for Linux in stable: language features	Tomas Sedovic	lang-docs	TC
		lang	Josh Triplett
		libs-api	n/a
		libs	n/a
Box notation for dyn async trait	Niko Matsakis	compiler
		lang	Niko Matsakis
Assumptions on Binders	Boxy	types
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
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	Niko Matsakis	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
		types
		spec	n/a
Project goal - High-Level ML optimizations	Manuel Drehwald	compiler	Oliver Scherer
		lang	TC
		infra	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
Experiment and RFC for #[manually_drop]		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
		types
		libs-api	n/a
Continue Experimentation with Pin Ergonomics	Frank King	compiler	Oliver Scherer
		lang	TC
Reborrow traits	Aapo Alasuutari	lang	Tyler Mandry
		compiler	n/a
		types	n/a
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
Implement Supertrait auto impl	Tyler Mandry	lang

Smaller/vibes goals

Smaller or vibes 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	types	n/a
		lang-docs	n/a
		spec	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	testing-devex	n/a
		cargo	n/a
		libs-api	n/a
Implement Open Rust Namespace Support		compiler	n/a
		cargo	n/a
Stabilize public/private dependencies		compiler	n/a
		cargo	n/a
Establish a Spot for Safety-Critical Lints in Clippy	Pete LeVasseur	clippy	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:

• Vibes: The team doesn’t need to do anything, but the goal author wants to know they support the idea.
• 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).

“Vibes” and “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: Discussion and moral support (from here)

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

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

clippy team

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

compiler team

*1: 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)

*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: Reviews of big changes needed; also looking for implementation help (from here)

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

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

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

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

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

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

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

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

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

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

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

*16: Reviewing any further compiler changes (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: Semantics, syntax, and stabilization decisions (from here)

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

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

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

*5: Design meeting, experiment (from here)

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

*7: 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)

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

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

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

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

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

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

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

*15: Design meeting Experiment (from here)

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

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

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

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

*20: Stabilization discussions (from here)

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

lang-docs team

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

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

*3: Thoughts on 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: Threading support will need review (from here)

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

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

*4: 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)

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: PR reviews for core/std public documentation; feedback on approach. (from here)

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

*5: 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)

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: Vibes on how this may align with other efforts to specify Rust. (from here)

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

testing-devex team

*1: Design discussions and review (from here)

types team

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

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

*3: Stabilization decision, solver work (from here)

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

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

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

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

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

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

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

*11: Discussion and moral support (from here)

wg-mir-opt team