Reference: all goals

This section contains the complete list of all 81 goals for 2026. There are a lot of them! You may prefer to look at the roadmaps to get a higher level picture of where Rust is going.

Goals

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
Allocators 1.0	Nia	libs	Nia
		lang	Josh Triplett
		compiler	n/a
		types	n/a
Allow turbofishing late bound vars	Oli Scherer	types	Boxy
		compiler	n/a
		lang	n/a
Arbitrary Self Types	Ding Xiang Fei	types	Jack Huey
		lang-docs	TC
		lang	Tyler Mandry
		libs	n/a
Architectural groundwork for expansion-time evaluation	Oli Scherer	compiler	Vadim Petrochenkov
		types	Oli Scherer
build-std	Adam Gemmell	cargo	Eric Huss
		compiler	n/a
		crates-io	n/a
		libs	n/a
Const Traits	Deadbeef	lang	TC
		types	Oli Scherer
		compiler	n/a
Evolving the standard library API across editions	Amanieu d’Antras	edition	Eric Huss
		libs	Amanieu d’Antras
		compiler	Jane Lusby
		rustdoc	Guillaume Gomez
		lang	n/a
		types	n/a
Field Projections		lang	Tyler Mandry
		compiler	Ding Xiang Fei
		types	Niko Matsakis
		libs	n/a
		opsem	Mario Carneiro
Full Const Generics	Boxy	lang	Niko Matsakis
		types	Boxy
Immobile types and guaranteed destructors	lcnr	lang	Jack Huey
		types	lcnr
MIR move elimination	Amanieu d’Antras	opsem	Ralf Jung
		compiler
		wg-mir-opt
		lang	Amanieu d’Antras
Next-Gen Region Constraints	Boxy	types	Boxy
Normative Documentation for Sound unsafe Rust	Pete LeVasseur	opsem	Ralf Jung
		lang-docs	n/a
		lang	n/a
		libs	n/a
Promoting Parallel Front End	Vadim Petrochenkov	wg-parallel-rustc	Vadim Petrochenkov
		compiler	n/a
Redesigning super let: Flexible Temporary Lifetime Extension	dianne	lang	TC
		compiler	dianne
		libs	n/a
reflection and comptime	Oli Scherer	lang	Scott McMurray
		compiler	Oli Scherer
		libs	Josh Triplett
		types	n/a
Specialization: minimal implementation	Jack Huey	types	Jack Huey
		lang	Tyler Mandry
		libs	n/a
		opsem	n/a
Stabilize and model Polonius Alpha	Rémy Rakic	types	Jack Huey
Stabilize FLS Release Cadence	Pete LeVasseur	fls	Pete LeVasseur
		spec	n/a
Stabilize the next-generation trait solver	lcnr	types	lcnr
		lang	Niko Matsakis

Medium goals

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

Goal	PoC	Team	Champion
f16b Primitive Type	James	compiler	David Wood
		lang	Tyler Mandry
Add an experimental TPDE compilation option	Manuel Drehwald	compiler	Manuel Drehwald
		bootstrap	n/a
Async Future Memory Optimisation	Ding Xiang Fei	compiler	Tyler Mandry
Async statemachine optimisation	Dion Dokter	compiler	Eric Holk
BorrowSanitizer	Ian McCormack	compiler	Ralf Jung
		opsem	Ralf Jung
		infra	n/a
		lang	Tyler Mandry
C interop: Complex<T>	Folkert de Vries	compiler	Folkert de Vries
		lang	n/a
		libs	n/a
C interop: f80, f128 and c_longdouble	Folkert de Vries	compiler
		lang	n/a
		libs	n/a
Cargo cross workspace cache	Ross Sullivan	cargo	Ed Page
Continue Experimentation with Pin Ergonomics ❌	Frank King	compiler	Oli Scherer
		lang	TC
		types	Oli Scherer
Contracts: primitive ownership assertions	Dawid Lachowicz	miri	Ralf Jung
		compiler	n/a
		lang	@Nadrieril
Control over Drop semantics	Jayan Sunil	compiler	Oli Scherer
		lang	@Nadrieril
		opsem	Crystal Durham
		types	n/a
Declarative (macro_rules!) macro improvements	Josh Triplett	lang	Josh Triplett
Dictionary Passing Style Experiment	@Nadrieril	types	lcnr
End-to-End Executable Rust Specification	@Nadrieril	formality	Niko Matsakis
		lang	n/a
		opsem	n/a
		types	n/a
Ergonomic ref-counting	Niko Matsakis	lang	Niko Matsakis
		compiler	n/a
		lang-docs	n/a
		libs	n/a
Experimental language specification ❌	Jack Huey	lang	Josh Triplett
		types	Jack Huey
		spec	n/a
Explicit tail calls & loop_match	Folkert de Vries	lang	Scott McMurray
		compiler	n/a
High-Level ML optimizations	Manuel Drehwald	compiler	Oli Scherer
		lang	TC
		infra	n/a
Implement and Maintain MC/DC Coverage Support	Dorian Péron	compiler	David Wood
		infra	n/a
Implement Supertrait auto impl	Ding Xiang Fei	lang	Taylor Cramer
		types	n/a
Implement Verifiable Mirroring Prototype	walterhpearce	cargo	Arlo Siemsen
		infra	Mark Rousskov
		rustup	Dirkjan Ochtman
		crates-io	Adam Harvey
Improve rustc_codegen_cranelift performance	bjorn3	compiler	bjorn3
		cargo	n/a
In-place initialization	Alice Ryhl	lang	Alice Ryhl
Incremental Systems Rethought	Alejandra González	compiler	Jack Huey
Library Trait Evolution Experiment	lcnr	lang	Tyler Mandry
		types	lcnr
		libs	n/a
Native async fn dynamic dispatch in traits	Santiago Pastorino	compiler	Santiago Pastorino
		lang	Jack Huey
		types	Jack Huey
Nightly support for function overloading in FFI bindings	teor	lang	Tyler Mandry
		compiler	n/a
		libs	n/a
		types	n/a
Open Enums	Alyssa Haroldsen	compiler	Mads Marquart
		lang	Scott McMurray
		libs	n/a
		opsem	Connor Horman
		types	n/a
Polymorphic code generation experiment	Noah Lev	compiler	Noah Lev
		types	n/a
Prepare TAIT + RTN for stabilization		lang	TC
		types	lcnr
Publish first version of rustc_public on crates.io	Makai	project-rustc-public	Celina G. Val
		compiler	n/a
Reborrow traits		lang	Tyler Mandry
		types	Oli Scherer
		compiler	n/a
Reintroduce a FCW system to borrowck	Oli Scherer	compiler	Oli Scherer
		types	lcnr
Sized Hierarchy and Scalable Vectors	David Wood	compiler	David Wood
		lang	Niko Matsakis
		libs	Amanieu d’Antras
		types	lcnr
Stabilize Cargo SBOM precursor		cargo	Weihang Lo
Stabilize MemorySanitizer and ThreadSanitizer Support	Jakob Koschel	compiler	Ramon de C Valle
		project-exploit-mitigations	Ramon de C Valle
		bootstrap	n/a
		infra	n/a
Stabilize public/private dependencies		compiler	Vadim Petrochenkov
		cargo	n/a
Stabilize Rust for Linux compiler features	Tomas Sedovic	compiler	Wesley Wiser
Stabilize the Try trait	MusicalNinjaDad	lang	Tyler Mandry
		libs	Amanieu d’Antras
		compiler	n/a
		types	n/a
View types experiment	Sasha Pourcelot	compiler	Oli Scherer
		lang	n/a
		types	n/a
Wasm Components	Yoshua Wuyts	compiler	Wesley Wiser
		lang	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
AArch64 Pointer Authentication using aarch64-unknown-linux-pauthtest target on Linux ELF platforms	Jakub Chlanda	compiler	David Wood
C++/Rust Interop Problem Space Mapping	teor	compiler	Oli Scherer
		lang	Tyler Mandry
		libs	David Tolnay
		opsem	n/a
Compiler performance optimizations	Nicholas Nethercote	compiler	n/a
		types	n/a
Continue resolving cargo-semver-checks blockers for merging into cargo	Predrag Gruevski	cargo	Ed Page
		rustdoc	Alona Enraght-Moony
Establish a Spot for Safety-Critical Lints in Clippy	Pete LeVasseur	clippy	n/a
Establish a User Research Team	Niko Matsakis	leadership-council	n/a
Expanding a-mir-formality to work better as a Rust type system spec	Jack Huey	lang-docs	n/a
		spec	n/a
		types	Jack Huey
Finish the libtest json output experiment		cargo	n/a
		libs	n/a
		testing-devex	n/a
Implement Open Rust Namespace Support		cargo	n/a
		compiler	n/a
Improving Unsafe Code Documentation in the Rust Standard Library	XU, Hui	libs	n/a
		opsem	n/a
Interactive cargo-tree: TUI for Cargo’s dependency graph visualization	Orhun Parmaksız	cargo	n/a
libc 1.0 release readiness	Yuki Okushi	crate-maintainers	n/a
Process-Safe Rustup Toolchain Operations	rami3l	rustup	n/a
Prototype a new set of Cargo “plumbing” commands		cargo	n/a
Stabilize Cargo’s linting system ✅	Ed Page	cargo	n/a
		clippy	n/a
		compiler	n/a
Stabilize cargo-script	Ed Page	cargo	n/a
		compiler	n/a
		lang	n/a
		rustdoc	n/a
Stabilize never type (!)	waffle	lang	n/a
		types	n/a
Stabilize Unsafe Fields	Jack Wrenn	book	n/a
		clippy	n/a
		lang	Niko Matsakis
		libs	n/a
		rustdoc	n/a
		rustfmt	n/a
		spec	n/a
		style	n/a
Stabilizing f16	Folkert de Vries	compiler	Trevor Gross
		lang	n/a
		libs	n/a
Type System Documentation	Boxy	types	Boxy

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.

book team

*1: Will need approval for book changes. (from here)

bootstrap team

*1: backup reviewer (Jakub Beránek) (from here)

cargo team

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

*2: Support needed for registry field design and resolver consistency. (from here)

*3: Design and code reviews (from here)

*4: Discussion and moral support (from here)

*5: Alignment on direction, possible integration help and review. (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)

*8: Code reviews and maybe a design discussion or two (from here)

clippy team

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

*2: Will need approval for clippy support. (from here)

*3: Review our initial batch of lints to ensure they provide an example of adapting the existing lint guidelines to Cargo (from here)

compiler team

*1: Significant refactoring of the resolver, reviews from Vadim Petrochenkov (from here)

*2: This feature touches callconv code, which requires careful review (from here)

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

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

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

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

*7: dedicated reviewer (Manuel Drehwald) (from here)

*8: Implementation reviews (Oli Scherer will review Proposal 2) (from here)

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

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

*11: PR Reviews, both of the RFC and of the subsequent implementation work (from here)

*12: reviewers: David Wood, bjorn3, Oli Scherer, Jubilee, Camille Gillot (from here)

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

*14: Targets are small but async fn is not (from here)

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

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

*17: The changes are not complicated, but touch some core types so this might need some design/refactoring to get right (from here)

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

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

*20: Standard reviews for maintainability of changes (from here)

*21: We expect to only need normal reviews. (from here)

*22: Discussion and moral support (from here)

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

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

*25: Coupling allocators to backend intrinsics (from here)

*26: Reviews for targeted optimizations (from here)

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

*28: Review our initial batch of lints to ensure they provide an example of adapting the existing lint guidelines to Cargo (from here)

crate-maintainers team

crates-io team

*1: Primarily focused on potential future logging/bandwidth savings. (from here)

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

formality team

*1: We’ll need help to usefully integrate with formality (from here)

infra team

*1: Critical for setting up the signing pipeline and Azure deployment. (from here)

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

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

lang team

*1: Aiming for two design meetings; large language feature (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: Semantics, syntax, and stabilization decisions (from here)

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

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

*8: RFC decision for RFC #3838, stabilization sign-off (from here)

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

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

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

*12: Some architectures cannot support guaranteed tail calls. Our current list of limitations is:

- wasm32/wasm64 need the tail-call target feature to be enabled
- powerpc (when elf1 is used) cannot tail call functions in other objects

Hence, rust code using guaranteed tail calls is not as portable as standard rust code. We need T-lang feedback on how to resolve this.

The all-hands is well-timed to figure out a solution. (from here)

*13: This is a stabilization, but we have previously explored the design in detail, and it’s simple and straightforward. It should be able to take place asynchronously. Nonetheless, I can upgrade this to “Large” if people believe it rises to that level. (from here)

*14: Probably want to have a lang meeting at some point (from here)

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

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

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

*18: Design meeting Experiment (from here)

*19: Reviewing trait evolution proposals (from here)

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

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

*22: These new types have a new ABI (from here)

*23: Stabilization discussions (from here)

*24: Ensure buy-in & alignment with this team (from here)

*25: Will need approval for stabilization. (from here)

*26: Most of the plans / design was already approved, only minor sign-offs required (from here)

*27: Not relevant yet, but in the future (from here)

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

*29: Suggestion of alternative syntaxes (from here)

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

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

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

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

*34: These new types have a new ABI (from here)

lang-docs team

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

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

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

leadership-council team

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

libs 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: Just a vibe check on the names and minimal APIs (from here)

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

*5: We would like to test some of the desired standard library changes and get input on the design (from here)

*6: Reviews, Stabilizations (from here)

*7: Will need approval for documentation changes. (from here)

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

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

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

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

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

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

*14: Just a vibe check on the names and minimal APIs (from here)

miri team

*1: Guidance on integration (from here)

opsem team

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

*2: Doc changes if necessary (from here)

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

*4: Ensure buy-in & alignment with this team (from here)

*5: Review pull requests; answer questions on Zulip when there are different opinions about specific rules (from here)

*6: Problem statement review (from here)

project-exploit-mitigations team

project-rustc-public team

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)

*4: Will need approval for rustdoc support. (from here)

rustfmt team

*1: Will need approval for rustfmt support. (from here)

rustup team

*1: Required for integrating the prototype into the primary toolchain installer. (from here)

*2: Members may have comments/thoughts on direction and priorities; Review work for t-rustup (from here)

spec team

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

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

*3: Will need approval for reference changes. (from here)

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

style team

*1: Will need approval for style guide changes. (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, reviews (from here)

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

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

*5: Be kept abrest of the design work and sign off on stabilizations (from here)

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

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

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

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

*10: Support for the restricted solver mode in the new solver (from here)

*11: MIR restructuring for borrowck (from here)

*12: Review and discuss type system changes if required (from here)

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

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

*15: r? types when touching the type system. Expect that anything beyond “simple” types changes may be rejected or de-prioritized. [^types-small] (from here)

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

*17: Ensure buy-in & alignment with this team (from here)

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

*19: Discussion and moral support (from here)

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

*21: We expect to only need normal reviews (from here)

*22: Reviews for trait solver optimizations (from here)

*23: Add the Contiguous marker trait and implied bound (from here)

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

*25: vibe check for erased types and which trait bounds to support (from here)

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

wg-mir-opt team

wg-parallel-rustc team

*1: Discussion and Implementation (from here)