Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

  • Feature Name: N/A
  • Start Date: (fill me in with today's date, YYYY-MM-DD)
  • RFC PR: rust-lang/rfcs#3849
  • Rust Issue: N/A

Summary

Propose a slate of 41 goals for 2025H2.

Motivation

The 2025h2 goal slate consists of 41 project goals, of which we have selected a subset as flagship goals. Flagship goals represent the highest priority being done by the various Rust teams.

Guide-level explanation

Rust's mission

Our goals are selected to further Rust's mission of making it dramatically more accessible to author and maintain foundational software—the software that underlies everything else. This includes the CLI tools and development infrastructure that developers rely on, the cloud platforms that run applications, the embedded systems in devices around us, and increasingly the kernels and operating systems that power it all.

Foundational software has particularly demanding requirements: reliability is paramount because when foundations fail, everything built on top fails too. Performance overhead must be minimized because it becomes a floor on what the layers above can achieve. Traditionally, meeting these requirements meant choosing between the power-but-danger of C/C++ or the safety-but-constraints of higher-level languages used in very specific ways.

Rust changes this balance by combining zero-cost abstractions with memory safety guarantees, often allowing you to write high-level code with low-level performance. While Rust's primary focus remains foundational software, we also recognize that supporting higher-level applications helps identify ergonomic improvements that benefit all users and enables developers to use Rust throughout their entire stack.

Flagship goals

This period we have 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) Rust builds, making Rust's builds fasterand 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 &'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" vesion 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 use throughout the compiler.
  • 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.
  • 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) Rust builds"

The "Flexible, fast(er) Rust builds" initiative focuses on improving Rust's build system to better serve both specialized use cases and everyday development workflows:

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

Project goals

The full slate of project goals are as follows. These goals all have identified points of contact who will drive the work forward as well as a viable work plan. The goals include asks from the listed Rust teams, which are cataloged in the reference-level explanation section below.

Invited goals. Some goals of the goals below are "invited goals", meaning that for that goal to happen we need someone to step up and serve as a point of contact. To find the invited goals, look for the Help wanted badge in the table below. Invited goals have reserved capacity for teams and a mentor, so if you are someone looking to help Rust progress, they are a great way to get involved.

GoalPoint of contactTeam(s) and Champion(s)
Develop the capabilities to keep the FLS up to datePete LeVasseurbootstrap (Jakub Beránek), lang (Niko Matsakis), opsem, spec (Pete LeVasseur), types
Getting Rust for Linux into stable Rust: compiler featuresTomas Sedoviccompiler (Wesley Wiser)
Getting Rust for Linux into stable Rust: language featuresTomas Sedoviclang (Josh Triplett), lang-docs (TC)
Borrow checking in a-mir-formalityNiko Matsakistypes (Niko Matsakis)
Nightly support for Autoreborrow traitsAapo Alasuutaricompiler (Oliver Scherer), lang (Tyler Mandry), types
build-stdDavid Woodcargo (Eric Huss), compiler (David Wood), libs (Amanieu d'Antras)
Prototype Cargo build analysisWeihang Locargo (Weihang Lo)
Rework Cargo Build Dir LayoutRoss Sullivancargo (Weihang Lo)
Prototype a new set of Cargo "plumbing" commandsHelp Wantedcargo
Stabilize cargo-scriptEd Pagecargo (Ed Page), compiler, lang (Josh Triplett), lang-docs (Josh Triplett)
Continue resolving cargo-semver-checks blockers for merging into cargoPredrag Gruevskicargo (Ed Page), rustdoc (Alona Enraght-Moony)
Emit Retags in CodegenIan McCormackcompiler (Ralf Jung), opsem (Ralf Jung)
Comprehensive niche checks for RustBastian Kerstingcompiler (Ben Kimock), opsem (Ben Kimock)
Const GenericsBoxylang (Niko Matsakis)
Ergonomic ref-counting: RFC decision and previewNiko Matsakiscompiler (Santiago Pastorino), lang (Niko Matsakis)
Evolving trait hierarchiesTaylor Cramercompiler, lang (Taylor Cramer), libs-api, types (Oliver Scherer)
Design a language feature to solve Field ProjectionsBenno Lossinlang (Tyler Mandry), types
Finish the std::offload moduleManuel Drehwaldcompiler (Manuel Drehwald), lang (TC)
Run more tests for GCC backend in the Rust's CIGuillaume Gomezcompiler (Wesley Wiser), infra (Marco Ieni)
In-place initializationAlice Ryhllang (Taylor Cramer)
C++/Rust Interop Problem Space MappingJon Baumancompiler (Oliver Scherer), lang (Tyler Mandry), libs (David Tolnay), opsem
Finish the libtest json output experimentEd Pagecargo (Ed Page), libs-api, testing-devex
MIR move eliminationAmanieu d'Antrascompiler, lang (Amanieu d'Antras), opsem, wg-mir-opt
Next-generation trait solverlcnrtypes (lcnr)
Implement Open API Namespace SupportHelp Wantedcargo (Ed Page), compiler (@BN), crates-io (Carol Nichols)
Promoting Parallel Front EndSparrow Licompiler
Continue Experimentation with Pin ErgonomicsFrank Kingcompiler (Oliver Scherer), lang (TC)
Stabilizable Polonius support on nightlyRémy Rakictypes (Jack Huey)
Production-ready cranelift backendFolkert de Vriescompiler, wg-compiler-performance
Stabilize public/private dependenciesHelp Wantedcargo (Ed Page), compiler
Expand the Rust Reference to specify more aspects of the Rust languageJosh Triplettlang-docs (Josh Triplett), spec (Josh Triplett)
reflection and comptimeOliver Scherercompiler (Oliver Scherer), lang (Scott McMurray), libs (Josh Triplett)
Relink don't RebuildJane Lusbycargo, compiler
Rust Vision DocumentNiko Matsakisleadership-council
rustc-perf improvementsJamescompiler, infra
Stabilize rustdoc doc_cfg featureGuillaume Gomezrustdoc (Tugce Ciftci)
Add a team charter for rustdoc teamGuillaume Gomezrustdoc (Tugce Ciftci)
SVE and SME on AArch64David Woodcompiler (David Wood), lang (Niko Matsakis), libs (Amanieu d'Antras), types
Rust Stabilization of MemorySanitizer and ThreadSanitizer SupportJakob Koschelbootstrap, compiler, infra, project-exploit-mitigations
Type System DocumentationBoxytypes (@boxy)
Unsafe FieldsJack Wrenncompiler (@jackwrenn), lang (Scott McMurray)

Reference-level explanation

Goals broken out by champion

Who is championing which goals?

Champion#Goals
Amanieu d'Antras3° MIR move elimination
° SVE and SME on AArch64
° build-std
@BN1° Implement Open API Namespace Support
Pete LeVasseur1° Develop the capabilities to keep the FLS up to date
Ralf Jung1° Emit Retags in Codegen
Wesley Wiser2° Getting Rust for Linux into stable Rust: compiler features
° Run more tests for GCC backend in the Rust's CI
Manuel Drehwald1° Finish the std::offload module
Alona Enraght-Moony1° Continue resolving cargo-semver-checks blockers for merging into cargo
@boxy1° Type System Documentation
Carol Nichols1° Implement Open API Namespace Support
Taylor Cramer2° Evolving trait hierarchies
° In-place initialization
David Wood2° SVE and SME on AArch64
° build-std
David Tolnay1° C++/Rust Interop Problem Space Mapping
Eric Huss1° build-std
Ed Page5° Continue resolving cargo-semver-checks blockers for merging into cargo
° Finish the libtest json output experiment
° Implement Open API Namespace Support
° Stabilize cargo-script
° Stabilize public/private dependencies
Tugce Ciftci2° Add a team charter for rustdoc team
° Stabilize rustdoc doc_cfg feature
Jack Huey1° Stabilizable Polonius support on nightly
@jackwrenn1° Unsafe Fields
Josh Triplett4° Expand the Rust Reference to specify more aspects of the Rust language
° Getting Rust for Linux into stable Rust: language features
° Stabilize cargo-script
° reflection and comptime
Jakub Beránek1° Develop the capabilities to keep the FLS up to date
lcnr1° Next-generation trait solver
Marco Ieni1° Run more tests for GCC backend in the Rust's CI
Niko Matsakis5° Borrow checking in a-mir-formality
° Const Generics
° Develop the capabilities to keep the FLS up to date
° Ergonomic ref-counting: RFC decision and preview
° SVE and SME on AArch64
Oliver Scherer5° C++/Rust Interop Problem Space Mapping
° Continue Experimentation with Pin Ergonomics
° Evolving trait hierarchies
° Nightly support for Autoreborrow traits
° reflection and comptime
Vadim Petrochenkov1° Delegation
Ben Kimock1° Comprehensive niche checks for Rust
Scott McMurray2° Unsafe Fields
° reflection and comptime
Santiago Pastorino1° Ergonomic ref-counting: RFC decision and preview
Tyler Mandry4° C++/Rust Interop Problem Space Mapping
° Design a language feature to solve Field Projections
° Emit Retags in Codegen
° Nightly support for Autoreborrow traits
TC3° Continue Experimentation with Pin Ergonomics
° Finish the std::offload module
° Getting Rust for Linux into stable Rust: language features
Weihang Lo2° Prototype Cargo build analysis
° Rework Cargo Build Dir Layout

Team asks

The following table highlights the asks from each affected team. The "owner" in the column is the person expecting to do the design/implementation work that the team will be approving.

bootstrap team

cargo team

*1: Review initial RFC draft (from here)

compiler team

*1: Approve experiment of [rfcs#3838] (from here)

*2: Most of our changes are within rustc_codegen_ssa, but it would also be helpful to have feedback from someone familiar with how retags are handled within Miri's borrow_tracker module. (from here)

*3: Where to insert the check / checked load (from here)

*4: Larger changes to rustc_codegen_ssa. While not strictly required, we think having a dedicated reviewer will speed up our progress. (from here)

*5: Review initial RFC draft (from here)

*6: Update performance regression policy (from here)

crates-io team

infra team

*1: rustc-perf improvements, testing infrastructure (from here)

lang team

*1: allows coding pre-RFC; only for trusted contributors (from here)

*2: Language team decide whether to accept [rfcs#3729] (from here)

*3: Compiler/Library team decide whether to accept [rfcs#3838] (from here)

*4: topic: adt_const_params design (from here)

*5: Possibly more than one required as well as discussions on zulip. (from here)

*6: Ding Xiang Fei, Benno Lossin (from here)

*7: Stabilizing arbitrary_self_types. Unblocked by new Receiver API. (from here)

*8: Needs libstd data structures (lang items) to make the specialization data available (from here)

*9: Two meetings to evaluate both approaches (from here)

*10: Choose between maximally additive vs seamlessly integrated (from here)

lang-docs team

GoalReference text
Expand the Rust Reference to specify more aspects of the Rust language
Getting Rust for Linux into stable Rust: language features
↳ Finish and stabilize arbitrary_self_types and derive_coerce_pointee
Stabilize cargo-script
↳ Stabilize language feature frontmatterEric Huss

leadership-council team

libs team

*1: Approve experiment of [rfcs#3838] (from here)

*2: Review initial RFC draft (from here)

*3: Needs libstd data structures (lang items) to make the specialization data available (from here)

libs-api team

*1: Stabilizing Receiver. Unblocked by implementation. (from here)

opsem team

*1: Most of our changes are within rustc_codegen_ssa, but it would also be helpful to have feedback from someone familiar with how retags are handled within Miri's borrow_tracker module. (from here)

project-exploit-mitigations team

rustdoc team

spec team

testing-devex team

types team

*1: request bandwidth from a second team, most features don't need this (from here)

*2: Assign specific reviewers for Polonius Alpha model implementation (Rémy Rakic) (from here)

*3: Review Part II of Sized Hierarchy implementation (from here)

*4: for necessary refactorings (from here)

wg-compiler-performance team

*1: track and show rustc_codegen_cranelift performance (from here)

wg-mir-opt team

Definitions

Definitions for terms used above:

  • Author RFC and Implementation means actually writing the code, document, whatever.
  • Design meeting means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
  • RFC decisions means reviewing an RFC and deciding whether to accept.
  • Org decisions means reaching a decision on an organizational or policy matter.
  • Secondary review of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review.
  • Stabilizations means reviewing a stabilization and report and deciding whether to stabilize.
  • Standard reviews refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
  • Other kinds of decisions:
    • Lang team experiments are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
    • Compiler Major Change Proposal (MCP) is used to propose a 'larger than average' change and get feedback from the compiler team.
    • Library API Change Proposal (ACP) describes a change to the standard library.

Frequently asked questions

How are project goals proposed?

Project goals are proposed bottom-up by a point of contact, somebody who is willing to commit resources (time, money, leadership) to seeing the work get done. The point of contact identifies the problem they want to address and sketches the solution of how they want to do so. They also identify the support they will need from the Rust teams (typically things like review bandwidth or feedback on RFCs). Teams then read the goals and provide feedback. If the goal is approved, teams are committing to support the point of contact in their work.

What goals were not accepted?

The following goals were not accepted as nobody stepped up to champion them. This should not be taken as a rejection of the underlying idea but likely indicates bandwidth constraints or concerns about scope.

GoalPoint of contactTeam(s) and Champion(s)
DelegationVadim Petrochenkovcompiler (Vadim Petrochenkov), lang

Does accepting a goal mean that the work is going to happen for sure?

No. Accepting a goal is not a promise to accept an RFC, stabilize a feature, or take any other binding action. Rather, it means that the team wants the goal to make progress and is committing to commit time to complete the Team Asks described in the goal. To give some concrete examples, when the compiler team accepts a goal, they are committing to make sure reviews get done, but they are not committing to give an r+ if the code doesn't pass muster. Similarly, the lang team is agreeing to discuss an RFC and provide actionable feedback, but not necessarily to accept it.

What is a "team champion"? What do they do?

Team champions are people who have volunteered to track progress on the goal and to serve as a liaison between the goal owner(s) and the team. They are committing to support the owner to avoid the goal getting stuck in some kind of procedural limbo. For example, the goal champion might make sure the goal gets discussed in a meeting, or help to find a reviewer for a PR that is stuck in the queue. (In cases where the goal owner is also on the team, they can serve as their own champion.)

What do the column names like "Ded. r?" mean?

Those column names refer to specific things that can be asked of teams:

AskakaDescription
"Allocate funds"Alloc fundsallocate funding
"Discussion and moral support"Good vibesapprove of this direction and be prepared for light discussion on Zulip or elsewhere
"Deploy to production"Deploydeploy code to production (e.g., on crates.io
"Standard reviews"r?review PRs (PRs are not expected to be unduly large or complicated)
"Dedicated reviewer"Ded. r?assign a specific person (or people) to review a series of PRs, appropriate for large or complex asks
"Lang-team experiment"Experimentbegin a lang-team experiment authorizing experimental impl of lang changes before an RFC is written; limited to trusted contributors
"Design meeting"Design mtg.hold a synchronous meeting to review a proposal and provide feedback (no decision expected)
"RFC decision"RFCreview an RFC and deciding whether to accept
"RFC secondary review"RFC rev.briefly review an RFC without need of a formal decision
"Org decision"Orgreach a decision on an organizational or policy matter
"MCP decision"MCPaccept a Major Change Proposal
"ACP decision"ACPaccept an API Change Proposal
"Review/revise Reference PR"Reference textassign a lang-docs team liaison to finalize edits to Rust Reference
"Stabilization decision"Stabilize.reach a decision on a stabilization proposal
"Policy decision"Policymake a decision related to team policy
"FCP decision(s)"FCPmake formal decision(s) that require 'checkboxes' and a FCP (Final Comment Period)
"Blog post approval"Blogapprove of posting about this on the main Rust blog
"Miscellaneous"Miscdo some one-off action as described in the notes

Do goals have to have champions to be accepted?

Yes -- to be accepted, a goal needs some champions. They don't necessarily have to have a champion for every team, particularly not those with minor asks, but they do need to have enough champions that it seems the goal owner will be adequately supported. Those champions also need to not be too overloaded.

How will we avoid taking on too many goals?

That's a tough one. Part of the reason to have champions is to help us filter out goals -- if one champion has too many goals, or nobody is willing to champion the goal, that's a bad sign.