Reference: all goals
This section contains the complete list of all 67 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.
Medium goals
Medium goals require support from an individual, the team champion.
Small goals
Small goals are covered by standard team processes and do not require dedicated support from anyone.
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
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize Unsafe Fields | Small | *1 |
*1: Will need approval for book changes. (from here)
bootstrap team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize MemorySanitizer and ThreadSanitizer Support | Small |
cargo team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| build-std | Large | Eric Huss | *1 |
| Implement Verifiable Mirroring Prototype | Medium | Arlo Siemsen | *2 |
| Cargo cross workspace cache | Medium | Ed Page | *3 |
| Stabilize Cargo SBOM precursor | Medium | Weihang Lo | |
| Finish the libtest json output experiment | Small | ||
| Prototype a new set of Cargo “plumbing” commands | Small | *4 | |
| Stabilize Cargo’s linting system | Small | *5 | |
| Interactive cargo-tree: TUI for Cargo’s dependency graph visualization | Small | *6 | |
Improve rustc_codegen_cranelift performance | Small | *7 | |
| Stabilize public/private dependencies | Small | ||
Continue resolving cargo-semver-checks blockers for merging into cargo | Small | Ed Page | *8 |
| Stabilize cargo-script | Small | Stabilization process | |
| Implement Open Rust Namespace Support | Small |
*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: PR reviews for Cargo changes; design discussions (from here)
*5: Code reviews and maybe a design discussion or two (from here)
*6: Alignment on direction, possible integration help and review. (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: Discussion and moral support (from here)
clippy team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize Cargo’s linting system | Small | *1 | |
| Stabilize Unsafe Fields | Small | *2 | |
| Establish a Spot for Safety-Critical Lints in Clippy | Small | *3 |
*1: Review our initial batch of lints to ensure they provide an example of adapting the existing lint guidelines to Cargo (from here)
*2: Will need approval for clippy support. (from here)
*3: Initial onboarding support for SCRC contributors; guidance on lint design (from here)
compiler team
*1: Significant refactoring of the resolver, reviews from Vadim Petrochenkov (from here)
*2: Review of implementation PRs; guidance on architecture to avoid previous maintenance issues (from here)
*3: Design discussions and implementation review. (from here)
*4: Standard reviews for stabilization and SVE work (from here)
*5: Champion: Ralf Jung. Design discussions, PR review, and upstream integration. (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: Reviews of big changes needed; also looking for implementation help (from here)
*8: Design discussions, PR review (from here)
*9: 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)
*10: Implementation reviews (Oliver Scherer will review Proposal 2) (from here)
*11: Most will be review work, but pushing optimisations to the max will possibly touch on some controversial points that need discussion (from here)
*12: Targets are small but async fn is not (from here)
*13: Review our initial batch of lints to ensure they provide an example of adapting the existing lint guidelines to Cargo (from here)
*14: Most complexity is in the type system (from here)
*15: Standard reviews for maintainability of changes (from here)
*16: Design discussions, PR review (from here)
*17: We expect to only need normal reviews. (from here)
*18: Reviewing any further compiler changes (from here)
*19: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)
*20: Design discussions, PR review (from here)
crate-maintainers team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| libc 1.0 release readiness | Small |
crates-io team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Implement Verifiable Mirroring Prototype | Small | Adam Harvey | *1 |
| build-std | Small | *2 |
*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
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Evolving the standard library API across editions | Large | Eric Huss | *1 |
*1: Review the feasibility of this proposal as well as the specific API changes. (from here)
fls team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize FLS Release Cadence | Large | Pete LeVasseur | *1 |
*1: Core work of authoring and releasing FLS versions on schedule (from here)
infra team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Implement Verifiable Mirroring Prototype | Medium | Mark Rousskov | *1 |
| Implement and Maintain MC/DC Coverage Support | Small | *2 | |
| BorrowSanitizer | Small | Upstream integration. | |
| High-Level ML optimizations | Small | *3 | |
| Stabilize MemorySanitizer and ThreadSanitizer Support | Small |
*1: Critical for setting up the signing pipeline and Azure deployment. (from here)
*2: CI support for MC/DC testing (from here)
*3: I will work with Jakub Beránek to add more bootstrap options to build and configure MLIR (an LLVM subproject) (from here)
lang team
*1: Would need a design meeting and RFC review. (from here)
*2: Design meeting, experiment (from here)
*3: Stabilization decisions, directional alignment (from here)
*4: Aiming for two design meetings; large language feature (from here)
*5: Semantics, syntax, and stabilization decisions (from here)
*6: Design session needed to work through design (from here)
*7: Review and accept a design space RFC (from here)
*8: RFC decision for RFC #3838, stabilization sign-off (from here)
*9: Stabilization decision for user facing changes (from here)
*10: 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)
*11: Champion and (ideally) a lang meeting (from here)
*12: Design meeting Experiment (from here)
*13: Continued experiment support, design feedback (from here)
*14: 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)
*15: Reviews, Lang/RfL meetings (from here)
*16: RFC review, design discussions (from here)
*17: Vibe check and RFC review (from here)
*18: 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)
*19: Team aligned already on the shape of the feature (from here)
*20: Most of the plans / design was already approved, only minor sign-offs required (from here)
*21: Review of the feature and lang implications. (from here)
*22: Champion: Tyler Mandry. General support and guidance. (from here)
*23: occasionally being fast-tracked would be nice (from here)
*24: Suggestion of alternative syntaxes (from here)
*25: Will need approval for stabilization. (from here)
*26: Stabilization discussions (from here)
*27: Experimentation with native Wasm features will need approval. May become “medium” if we are somehow really successful. (from here)
*28: Feedback on language semantics questions as needed (from here)
lang-docs team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Arbitrary Self Types | Medium | TC | *1 |
| Ergonomic ref-counting | Small | ||
| Expanding a-mir-formality to work better as a Rust type system spec | Small | *2 | |
Normative Documentation for Sound unsafe Rust | Small | *3 |
*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
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Establish a User Research Team | Small | *1 |
*1: Org decision to establish team, ongoing coordination (from here)
libs team
| Goal | Level | Champion | Notes |
|---|---|---|---|
Redesigning super let: Flexible Temporary Lifetime Extension | Small | *1 | |
| Open Enums | Small | Changes to derive | |
| Field Projections | Small | *2 | |
| Improving Unsafe Code Documentation in the Rust Standard Library | Small | Review pull requests; | |
| Stabilize Unsafe Fields | Small | *3 | |
| Design, model, and implement a stabilizable-subset of specialization | Small | ||
| Arbitrary Self Types | Small | Reviews | |
| build-std | Small | *4 | |
| Wasm Components | Small | *5 |
*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: Will need approval for documentation changes. (from here)
*4: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)
*5: Threading support will need review (from here)
libs-api team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Evolving the standard library API across editions | Large | Amanieu d’Antras | *1 |
| Stabilize the Try trait | Medium | Amanieu d’Antras | |
| reflection and comptime | Medium | Josh Triplett | Reviews |
| Sized Hierarchy and Scalable Vectors | Medium | Amanieu d’Antras | *2 |
| Finish the libtest json output experiment | Small | ||
| Ergonomic ref-counting | Small | *3 | |
| Nightly support for function overloading in FFI bindings | Small | *4 | |
Stabilizing f16 | Small | ||
| Field Projections | Small | Reviews of RFC | |
| C++/Rust Interop Problem Space Mapping | Small | David Tolnay | Reviews |
| Arbitrary Self Types | Small | Stabilizations | |
Normative Documentation for Sound unsafe Rust | Small | *5 |
*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
| Goal | Level | Champion | Notes |
|---|---|---|---|
| MIR move elimination | Large | Ralf Jung | Design meeting |
Normative Documentation for Sound unsafe Rust | Large | Ralf Jung | *1 |
| BorrowSanitizer | Medium | Ralf Jung | Champion: Ralf Jung. |
| Open Enums | Small | Connor Horman | *2 |
| Field Projections | Small | Mario Carneiro | *3 |
| Improving Unsafe Code Documentation in the Rust Standard Library | Small | *4 | |
| Design, model, and implement a stabilizable-subset of specialization | Small | ||
| C++/Rust Interop Problem Space Mapping | Small | *5 | |
| Control over Drop semantics | Small | Crystal Durham |
*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: Review pull requests; answer questions on Zulip when there are different opinions about specific rules (from here)
*5: Problem statement review (from here)
project-exploit-mitigations team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize MemorySanitizer and ThreadSanitizer Support | Medium | Ramon de C Valle | Dedicated reviewer |
rustdoc team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Evolving the standard library API across editions | Medium | Guillaume Gomez | *1 |
| Stabilize Unsafe Fields | Small | *2 | |
Continue resolving cargo-semver-checks blockers for merging into cargo | Small | Alona Enraght-Moony | *3 |
| Stabilize cargo-script | Small | *4 |
*1: Figure out how such API changes should be presented in the API docs. (from here)
*2: Will need approval for rustdoc support. (from here)
*3: Discussion and moral support (from here)
*4: Design decision and PR review (from here)
rustfmt team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize Unsafe Fields | Small | *1 |
*1: Will need approval for rustfmt support. (from here)
rustup team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Implement Verifiable Mirroring Prototype | Medium | Dirkjan Ochtman | *1 |
*1: Required for integrating the prototype into the primary toolchain installer. (from here)
spec team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize FLS Release Cadence | Small | *1 | |
| Stabilize Unsafe Fields | Small | *2 | |
| Expanding a-mir-formality to work better as a Rust type system spec | Small | *3 | |
| Experimental language specification | Small | *4 |
*1: Alignment on release cadence goal (from here)
*2: Will need approval for reference changes. (from here)
*3: General discussion of integration of a-mir-formality with reference (from here)
*4: General discussion on how this may align with other efforts to specify Rust. (from here)
style team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Stabilize Unsafe Fields | Small | *1 |
*1: Will need approval for style guide changes. (from here)
testing-devex team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Finish the libtest json output experiment | Small | *1 |
*1: Design discussions and review (from here)
types team
*1: a-mir-formality modeling, design alignment, reviews (from here)
*2: Stabilization decision, ongoing review work (from here)
*3: Implementation design and sign-off (from here)
*4: Involved in implementation + review (from here)
*5: Review of type-system stabilization/implementation (from here)
*6: Design review, stabilization decision, reviews from Jack Huey and Matthew Jasper (from here)
*7: Support for the restricted solver mode in the new solver (from here)
*8: Type System implementation and stabilization sign-off (from here)
*9: implementation/reviews/deciding on a design (from here)
*10: Collaborating on a-mir-formality on the borrow checker integration; small reviews of RFC and/or compiler PRs (from here)
*11: MIR restructuring for borrowck (from here)
*12: Evaluate potential changes to (experimental) reference in routine team decisions (from here)
*13: Stabilization report review, TAIT interactions (from here)
*14: General discussion on any additional type-system changes (from here)
*15: May have changes to dyn-compatibility rules (from here)
*16: We expect to only need normal reviews (from here)
*17: Review of any changes to HIR ty lowering or method resolution (from here)
*18: Discussion and moral support (from here)
*19: No dedicated reviewer needed/given, but tracking issue should note the needed for dedicated types review prior to stabilization (from here)
*20: Add the Contiguous marker trait and implied bound (from here)
*21: Members may have comments/thoughts on direction and priorities; Review work for a-mir-formality (from here)
*22: r? types when touching the type system. Expect that anything beyond “simple” types changes may be rejected or de-prioritized. [^types-small] (from here)
wg-mir-opt team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| MIR move elimination | Medium | Design meeting |
wg-parallel-rustc team
| Goal | Level | Champion | Notes |
|---|---|---|---|
| Promoting Parallel Front End | Large | Vadim Petrochenkov | *1 |
*1: Discussion and Implementation (from here)