Rust Blog

Project goals update — April 2026 (end of 2025H2)

2026-05-18T00:00:00+00:00

The 2025H2 Project Goal period has now concluded. Over these months, the Rust Project pursued 41 Project Goals, 13 of which were designated as Flagship Goals. This post contains curated updates on our progress since the last post and the final status for each of the goals (many of which continue as part of the 2026 period). Full details for any particular goal are available in its tracking issue.

Thanks to everyone who contributed! <3

Flagship: Beyond the &
Flagship: Flexible, fast(er) compilation
Flagship: Higher-level Rust
- Ergonomic ref-counting: RFC decision and preview
- Stabilize cargo-script
Flagship: Unblocking dormant traits
Other goal updates

Flagship: Beyond the `&`

Continue Experimentation with Pin Ergonomics

People involved: Frank King
Champions: compiler (Oliver Scherer), lang (TC)
Status: Continued

3 detailed updates available.

Frank King — comment from 2026-02-26
(Just come back from the Spring Festival)
- (locally, no PR yet): design and implement the borrow checking algorithms of &pin
- Reviewed Add Drop::pin_drop for pinned drops, to update the submodule book
- Reviewed Implement coercions between &pin (mut|const) T and &(mut) T when T: Unpin, to do some refactors according to the reviewed messages.
Frank King — comment from 2026-03-16
- Merged Implement coercions between &pin (mut|const) T and &(mut) T when T: Unpin.
- Opened draft PR Implement borrowck for &pin mut|const $place. The implementation needs to be refined and self-reviewed before the community reviews.
Frank King — comment from 2026-04-16

Self-reviewed Implement borrowck for &pin mut|const $place. Found that the current approach of handling pinned borrows may be incorrect, as it failed to distinguish a pinned borrow from a coercion of a normal-to-pinned reference. The latter doesn't prevent a T: Unpin type from being moved, but the former does, which breaks the pin coercion test.

Design a language feature to solve Field Projections

People involved: Benno Lossin
Champions: lang (Tyler Mandry)
Status: Continued

5 detailed updates available.

Benno Lossin — comment from 2026-01-01
- At the beginning of December, we set out to answer five important questions regarding the virtual places approach. We discussed four questions and arrived at answers for three.
  - The first question we looked at was question 3 Canonical Projections.
  - Next we looked at question 4 Non-Indirected Containers.
  - As the final question we answered, we looked at question 1 Field-by-Field Projections vs One-Shot Projections.
  - At the moment, we are investigating question 2 and I wrote a blog post with a potential solution that still needs feedback.
- We started a Wiki Project to consolidate our knowledge in one place.
  - We implemented an algorithm to determine the type of a place expression.
- Our plan is to continue this project goal in the next goal period.
Benno Lossin — comment from 2026-01-25

Earlier this month, Nadrieril Ding Xiang Fei and I held a meeting on autoref and method resolution in a world with field projections. This meeting resulted in a new page for the wiki on autoref.

Benno Lossin — comment from 2026-02-28

The first pull request of the lang experiment has just been merged: rust-lang/rust#152730

This PR enables the use of the field_of! macro to obtain a unique type for each field of a struct, enum variant, tuple, or union. We call these types field representing types (FRTs). When the base type is a struct that is not repr(packed), only contains Sized fields, this type automatically implements the Field trait that exposes some information about the field to the type system. The offset in bytes from the start of the struct, the type of the field and the type of the base type.

The feature is still incomplete and highly experimental. We also want to tackle the limitations in future PRs. For the moment this is enough to give us the ability to experiment with library versions of field projections and write functions that are generic over the fields of structs. For example one can write code like this:
#![feature(field_projections)]

use std::field::{Field, field_of};
use std::ptr;

fn project_ref<'a, T, F: Field<Base = T>>(r: &'a T) -> &'a F::Type {
    // SAFETY: the `Field` trait guarantees that this is sound.
    unsafe { &*ptr::from_ref(r).byte_add(F::OFFSET).cast() }
}

struct Struct {
    field: i32,
    other: u32,
}

fn main() {
    let s = Struct { field: 42, other: 24 };
    let r = &s;
    let field = project_ref::<_, field_of!(Struct, field)>(r);
    let other = project_ref::<_, field_of!(Struct, other)>(r);
    println!("field: {field}"); // prints 42
    println!("other: {other}"); // prints 24
}
A very important feature of the types returned by field_of! is that you can implement traits for them if you own the base type. This allows anointing fields with information by extending the Field trait. For example, this allows encoding the property of being a structurally pinned field:
use std::pin::Pin;

unsafe trait PinnableField: Field {
    type StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a;

    fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a;
}

fn project_pinned<'a, T, F>(r: Pin<&'a mut T>) -> <F as PinnableField>::StructuralRefMut<'a>
where
    F: PinnableField<Base = T>,
{
    F::project_mut(r)
}
We can then implement this extra trait for all of the fields of our struct (and automate that with a proc-macro):
unsafe impl PinnableField for field_of!(Struct, field) {
    type StructuralRefMut<'a> = &'a mut i32;

    fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a,
    {
        let base = unsafe { Pin::into_inner_unchecked(base) };
        &mut base.field
    }
}

unsafe impl PinnableField for field_of!(Struct, other) {
    type StructuralRefMut<'a> = Pin<&'a mut u32>;
    // u32 is `Unpin`, so this isn't doing anything special, but it highlights the pattern.

    fn project_mut<'a>(base: Pin<&'a mut Self::Base>) -> Self::StructuralRefMut<'a>
    where
        Self::Type: 'a,
        Self::Base: 'a,
    {
        let base = unsafe { Pin::into_inner_unchecked(base) };
        unsafe { Pin::new_unchecked(&mut base.other) }
    }
}
Now you can safely obtain a pinned mutable reference to other and a normal mutable reference to field by calling the project_pinned function and supplying the correct FRT.

(playground link)

Benno Lossin — comment from 2026-03-20
Plan for 2026

We have an updated plan for this goal in 2026 consisting of three major steps:
- a-mir-formality,
- Implementation,
- Experimentation.
Some of their subtasks depend on other subtasks for other steps. You can find the details in the updated tracking issue. Here is a short rundown of each:

a-mir-formality: we want to create a formal model of the borrow checker changes we're proposing to ensure correctness. We also want to create a document explaining our model in a more human-friendly language. To really get started with this, we're blocked on the new expression based syntax in development by Niko.

Implementation: at the same time, we can start implementing more parts in the compiler. We will continue to improve FRTs, while keeping in mind that we might remove them if they end up being unnecessary. They still pose for a useful feature, but they might be orthogonal to field projections. We plan to make small and incremental changes, starting with library additions. We also want to begin exploring potential desugarings, for which we will add some manual and low level macros. When we have that figured out, we can fast-track syntax changes. When we have a sufficiently mature formal model of the borrow checker integration, we will port it to the compiler. After further evaluation, we can think about removing the incomplete_feature flag.

Experimentation: after each compiler or standard library change, we look to several projects to stress-test our ideas in real code. I will take care of experimentation in the Linux kernel, while Tyler Mandry will be taking a look at testing field projections with crubit. Josh Triplett also has expressed eagerness of introducing them in the standard library; I will coordinate with him and the rest of t-libs-api to experiment there.
Benno Lossin — comment from 2026-04-02
Yesterday, we held a t-lang design meeting on our current approach. Nadrieril and I authored a design document with the feedback of Tyler Mandry, Ding Xiang Fei, Alice Ryhl, and Gary Guo. In this document, we provided the motivation for this feature, what the look and feel of a solution fitting into the existing features of Rust is, and a comprehensive + compact introduction to our current approach based on virtual places.

The general reception was extremely positive. To give some concrete quotes from the meeting:
- Josh:
  
  I adore this! I love how orthogonal it is, and how impactful and universal it is. I anticipate this becoming a beloved, pervasive feature of Rust.
  
  Places and projection seem important enough to me that they're worth giving one of our precious remaining ASCII sigils to, and @ is nicely evocative of a place (something is at a place). So to the extent the final syntax benefits from a sigil, :+1: for giving this @. (See some feedback below on the details, though.)
- TC:
  
  Love it. High concept. As I said in the last meeting:
  
  I particularly like language features that reduce the need for library surface area, and this is one of those.
  
  There are, of course, many details to resolve and understand further, e.g., with respect to migration issues, interaction with const, async, and other effect-like things, etc. I'm looking forward to seeing the formalization work.
- tmandry:
  
  What I love about this direction is how effectively it builds on what Rust already has. I love to see designs that reinforce our existing concepts while pushing them in directions that make them more expressive.
- Jack:
  
  Whoo boy. This is great. There's so much here that I'm not exactly sure where to begin and what to comment on. I think this is the type of thing that we will only really be able to figure out the nitty gritty details and ergonomics only after some amount of experimentation.
There are a few takeaways from this meeting:
- Mark raised the concern that t-libs should be more involved in reviewing the experimental traits that we intend to add. Ensuring that we don't accidentally stabilize or expose some behavior, have sufficient documentation on our experimental traits, and that t-libs is in the loop of this feature in general.
  - Mark offered to review PRs and I will be tagging him in those.
- Jack raised the concern that increasing the cognitive load for the 95% use-case should be avoided. Making the right choice between @ and & might be challenging for users.
  - We discussed this point more in the meeting and concluded with that we need to do some experimentation, possibly utilizing the user research team. We will of course keep this in mind and revisit it later when we have a partially working implementation.
- TC requested that we publish our fine-grained design axioms, essentially the list of things we go through when considering a modification of our proposal.
  - I will write an update on this issue explaining exactly those.
Aside from the concerns and directly actionable items, the meeting also covered design questions/comments that we want to take a look at in the coming weeks/months:
Thanks to everyone who participated in the meeting!

Reborrow traits

People involved: Aapo Alasuutari
Champions: compiler (Oliver Scherer), lang (Tyler Mandry)
Status: Continued

1 detailed update available.

Aapo Alasuutari — comment from 2026-02-28
PR open to get the first working version of the Reborrow and CoerceShared traits merged.

Blockers

Currently "blocked" on PR review, and of course my (and Ding's) work to fix all review issues.

The review has brought up an opportunity to replace Rvalue::Ref / ExprKind::Ref with a more generalised variant that could encompass both references and user-defined references. This would be powerful, but it would be a very big and scary change. If this turns out to be a blocking issue for reviewers, then this will block the goal for the foreseeable future as the PR then starts on a massive refactoring.

Help wanted

The PR currently does not include derive traits, but we'd really want them. Instead of these:
```
impl<'a> Reborrow for CustomMarker<'a> {}
impl<'a> CoerceShared<CustomMarkerRef<'a>> for CustomMarker<a'> {}

impl<'a, T> Reborrow for CustomMut<'a, T> {}
impl<'a, T> CoerceShared<CustomRef<'a, T>> for CustomMut<'a, T> {}
```
we'd prefer to have something like this:
```
#[derive(Reborrow, CoerceShared(CustomMarkerRef))]
struct CustomMarker<'a> { ... }

#[derive(Reborrow, CoerceShared(CustomRef))]
struct CustomMut<'a, T> { ... }
```
If anyone feels like picking up this thread, that'd be awesome: the derive macros do not need to really perform any validity checking, as the trait itself will do that.

If the PR merges soon, then public testing and exploration of the traits will be the next big thing. Likely concurrently with that the massive refactoring to generalise Rvalue::Ref / ExprKind::Ref.

Flagship: Flexible, fast(er) compilation

build-std

People involved: David Wood, Adam Gemmell
Champions: cargo (Eric Huss), compiler (David Wood), libs (Amanieu d'Antras)
Status: Continued

4 detailed updates available.

David Wood — comment from 2026-01-15

rust-lang/rfcs#3873 has been merged and an FCP has been started on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 - those both have some feedback for me to respond to that I'll get to as soon as I can.
David Wood — comment from 2026-02-17

No major updates this cycle - we're still working through feedback on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and prototyping the implementation to be prepared.
David Wood — comment from 2026-03-17

Update this cycle is the same as last time - rust-lang/rfcs#3874 and rust-lang/rfcs#3875 are progressing, with feedback being addressed and checkboxes checked, and we're still working out what the implementation would look like.
David Wood — comment from 2026-04-14

rust-lang/rfcs#3874 has finished FCP and is due to be merged any day now. I'm working on resolving the remaining open comments on rust-lang/rfcs#3875 and then intend to nudge the reviewers to have a look and check their boxes or leave concerns.

Adam Gemmell has opened rust-lang/cargo#16675 with an early sketch of some of the core changes that build-std would require and is working with the Cargo team to address feedback and work out how to proceed with the implementation.

Production-ready cranelift backend

People involved: Folkert de Vries, bjorn3, Trifecta Tech Foundation
Champions: compiler (bjorn3)
Status: Not completed (lack of funding)

Promoting Parallel Front End

People involved: Sparrow Li
Status: Continued

Relink don't Rebuild

People involved: Jane Lusby, @dropbear32, @osiewicz
Champions: cargo (Weihang Lo), compiler (Oliver Scherer)
Status: Not completed (note)

Flagship: Higher-level Rust

Ergonomic ref-counting: RFC decision and preview

People involved: Niko Matsakis, Santiago Pastorino
Champions: compiler (Santiago Pastorino), lang (Niko Matsakis)
Status: Continued

Stabilize cargo-script

People involved: Ed Page
Champions: cargo (Ed Page), lang (Josh Triplett), lang-docs (Josh Triplett)
Status: Continued

3 detailed updates available.

Ed Page — comment from 2026-01-14
#146377 has been decided and merged.

Blockers
- T-lang discussing CR / text direction feedback: comment
- T-rustdoc deciding on and implementing how they want frontmatter handled in doctests
Ed Page — comment from 2026-02-13
- FCP has ended on frontmatter support, just awaiting merge
- Cargo script has entered FCP
Blockers
- Potential issues around edition, see Cargo script edition policy (lang/edition aspects).
Ed Page — comment from 2026-03-16
Cargo's FCP has ended.

Blockers
- Cargo script edition policy (lang/edition aspects)

Flagship: Unblocking dormant traits

Evolving trait hierarchies

People involved: Taylor Cramer and others
Champions: lang (Taylor Cramer), types (Oliver Scherer)
Status: Superseded by the Implement Supertrait auto impl and Arbitrary Self Types 2026 goals

In-place initialization

People involved: Alice Ryhl, Benno Lossin, Michael Goulet, Taylor Cramer, Josh Triplett, Gary Guo, Yoshua Wuyts
Champions: lang (Taylor Cramer)
Status: Continued

1 detailed update available.

Alice Ryhl — comment from 2026-01-31

A proposal to continue this goal in the next goal period was merged.

Next-generation trait solver

People involved: lcnr, Boxy, Michael Goulet
Champions: types (lcnr)
Status: Continued

1 detailed update available.

lcnr — comment from 2026-01-19

There hasn't been too much progress over the last few weeks and I've been mostly taking a Christmas break. Nicholas Nethercote has been looking into the performance of the new trait solver, cleaning up canonicalization and slightly improving its performance: PR 1 and PR 2.

Shoyu Vanilla looked into ICE from mir validation on unsizing in opendal and uncovered the underlying bug there. While this issue also affects the old solver and the proper fix for it requires where-bounds on binders, we can work around this bug in the trait solver for now and intend to do so.

We've started another crater run with all our recent changes and adwin has started to triage it, uncovering one new issue up until now. Intend to continue going through that over the next few weeks.

There's also a lot in-progress work going on. I am collaborating with Niko Matsakis to specify and later RFC the cycle semantics of Rust. León Orell Valerian Liehr is working on a replacement for the rustdoc's auto trait impl synthesis. tiif is working on a fix a MIR borrowck unsoundness. Shoyu Vanilla and I are improving the way we propagate inference constraints from the expected return type to function arguments, fixing this issue.

Stabilizable Polonius support on nightly

People involved: Rémy Rakic, Amanda Stjerna, Niko Matsakis
Champions: types (Jack Huey)
Status: Continued

2 detailed updates available.

Rémy Rakic — comment from 2026-01-30
This month's update:
- tiif is making progress on normalizing opaques while computing implied bounds
- we discussed how to investigate and fix the remaining correctness issues in Tage's work, to be able to evaluate it more accurately: in particular around variance and bidirectional edges, and without the reliance on NLL (having computed region values / errors)
- we've tried to see if it'd be possible to remove the cfg region elements
- Amanda is still working on her two papers, one about the current borrow checker and one about the work on Polonius. Her major PR for the restructuring of placeholder handling during region inference is stalled due to a conflict with further trait solver developments and may have to be abandoned. Work with the larger types team is ongoing and smaller patches/refactorings/improvements are being landed in the meantime.
- #149639 has now landed, and #150551 is still in review
- I've also fixed more small inefficiencies (computing boring/relevant locals on-demand in diagnostics, removed conversions between locations and points, etc) building on top of the previous PRs (so they need to be reviewed first)
- I've looked at crates.io again with the alpha, to find functions that are slower than with NLLs. AFAICT the worst case there is 60% for a 5KLOC function with 42K loans, 255K statements, and 125K outlives constraints. I'll see what we can do with this. Small composable functions is still good advice.
- there seem to be optimization opportunities to 1. limit propagation to the smaller number of blocks that could be affected by bidirectional edges, 2. for unifying invariant lifetimes of live locals that are assigned at most once (à la use-def chains), 3. for invalidations that are just the activation of a reservation
- we discussed possible plans to gather actual statistics, using the infrastructure that was created for the Metrics project
- we're also preparing the new project goal for this year, where we'll want to stabilize the alpha 🤞
Rémy Rakic — comment from 2026-02-28
We had a bit less time this month, the update will be shorter, but still meaningful I hope:
- #150551 has landed, and it feels stabilizable. To me, this part of the goal is achieved.
- still, "stabilizable" is not stable, and there is more work to do. We plan to stabilize this year, and the project goal proposal for 2026 tracks how.
- tiif is still deep in #152051, and a-mir-formality work with Niko and I.
- Amanda has opened a few cleanup PRs (#152438, and #152579), and #151863 has landed already. She also has started looking into Tage's old PR to see if we can fix it, benchmark it more accurately, and see the cool parts there that we could be using.
- Jack is possibly going to have some time to work with us this year! His help will be very welcome, especially as I will have less time available myself.
- we'll be tracking the opaque type region liveness soundness issue in #153215, and I've added a couple tests, in case tiif's PR or anything that impacts them lands.
- some of the tiny cleanups I mentioned last time have also landed in #152587.

Other goal updates

Add a team charter for rustdoc team

People involved: Guillaume Gomez
Champions: rustdoc (Guillaume Gomez)
Status: Completed

Borrow checking in a-mir-formality

People involved: Niko Matsakis, tiif
Champions: types (Niko Matsakis)
Status: Continued

C++/Rust Interop Problem Space Mapping

People involved: Joel Marcey
Champions: compiler (Oliver Scherer), lang (Tyler Mandry), libs (David Tolnay)
Status: Continued

5 detailed updates available.

Joel Marcey — comment from 2026-01-20

The Rust Foundation is opening up a short-term, approximately 3-month, contracting role to assist in our Rust/C++ Interop initiative. The primary work and deliverables for the role will be to make substantial progress on the Problem Space Mapping Rust Project Goal by collecting discrete problem statements and offering up recommendations on the work that should follow based upon the problems that you found.

If you are interested in how programming languages interoperate, are curious in understanding the problems therein, and are have a passion to think about how those problems may be resolved for the betterment of interop, then this work may be for you.

An ideal candidate will have experience with Rust programming. Having experience in C++ is strongly preferred as well. If you have direct experience with actual engineering that required interoperating between Rust and C++ codebases, that's even better.

If you are interested, please email me (email address found in my GitHub profile) or contact me directly on Zulip by Tuesday, January 27 and we can take it from there to see if there may be a potential fit for further discussion.

Thank you.
Joel Marcey — comment from 2026-01-31

The effort to fill the contracting role to support this project goal is in the process winding down. The interview and discussion process is nearly complete. We expect to make a final decision for the role in early February.
teor — comment from 2026-02-27
Hi, I'm the new contractor on the interop problem space mapping project goal.

In the last week and a half, I've:
- added some draft high-level problem statement summaries
- started mapping out interop use cases
- added relationships between problems/use cases and existing project goals & unstable compiler features
Next step is prioritising a few of the use cases, then working on related problem statements in more detail.

Blockers

Nothing at the moment, still working through the high level mapping of the problem space.

Help wanted

Suggestions for more interop use cases would be very welcome, just open a discussion in t-lang/interop and I'll turn it into a ticket. Or go ahead and open a use case ticket directly.

I'll post an update here every few weeks, you can follow more detailed weekly updates on Zulip.
teor — comment from 2026-03-30
In the last month, I've:
- met with the lang team, Crubit team, and cxx author, and Joel and Mara have met with the C++ standards working group
- expanded some draft high-level problem statement summaries, and added code examples
- added 6 new interop use cases
- added more relationships between problems/use cases and existing project goals & unstable compiler features
- prepared for the Rust All Hands, and started mentoring for Outreachy
Specifically, the last month we've identified and prioritised two high-priority use cases for more detailed work:
- calling an overloaded C++ function from Rust, with a Rust lang experiment - implementation discussion
- adding Rust to an existing C++ build system, this currently works for basic cases, but the tooling could be improved on the Rust side
And I analysed the problems / use cases we've collected so far, with priorities, responsible language, and a split into semantics or tooling changes.

Next step is continuing to work on overloading and build systems in more detail. If you have specific Rust/C/C++ build system blockers, please open a chat or ticket.

Blockers

Nothing at the moment, everyone has been extremely helpful, and I'm getting good feedback on use cases, problems, priorities, and Rust language experiments.
teor — comment from 2026-05-01
In the last month, I've:
- prepared for RustWeek and the All Hands, where I will be giving a Rust Project track talk and running an All Hands interop session (schedule TBC)
- added new interop use cases and problem statements, and continued categorising them using GitHub tags
- continued to expand the draft high-level problem statement summaries
- added interop code examples, including many examples from Outreachy applicants
- continued mentoring Outreachy applicants
- continued working on the Overloading Rust language experiment
Specifically, the last month we've made detailed progress on two high-priority use cases:
- calling an overloaded C++ function from Rust, with a Rust lang experiment - implementation discussion
  - we've merged a refactor to prepare for this experiment, which gave some nice perf wins
  - the initial overloading experiment PR has been through two rounds of review, and is waiting for my revisions and rebasing
- adding Rust to an existing C++ build system
  - Outreachy applicants wrote interop example code PRs
  - these interop user experiences are waiting for analysis, so they can be summarised in the build system and overloading problem statements
  - this will likely happen after RustWeek and the All Hands
Next step is continuing to work on the overloading experiment, along with RustWeek/All Hands preparation, and collecting feedback during the conference.

Blockers

Nothing at the moment. There is a steady stream of new use cases, problems, code examples and Rust language experiment feedback.

Comprehensive niche checks for Rust

People involved: Bastian Kersting, Jakob Koschel
Champions: compiler (Ben Kimock), opsem (Ben Kimock)
Status: Not completed

Const Generics

People involved: Boxy, Noah Lev
Champions: lang (Niko Matsakis)
Status: Continued

6 detailed updates available.

Niko Matsakis — comment from 2026-01-27

Boxy and I have established a regular time to check-in on formalizing this within a-mir-formality. Today we mostly worked on the "model" of const values, starting with this

#[term]
pub enum ConstData {
    // Sort of equivalent to `ValTreeKind::Branch`
    #[cast]
    RigidValue(RigidConstData),

    // Sort of equivalent to `ValTreeKind::Leaf`
    #[cast]
    Scalar(ScalarValue),

    #[variable(ParameterKind::Const)]
    Variable(Variable),
}



#[term]
pub enum ScalarValue {
    #[grammar(u8($v0))]
    U8(u8),
    #[grammar(u16($v0))]
    U16(u16),
    #[grammar(u32($v0))]
    U32(u32),
    #[grammar(u64($v0))]
    U64(u64),
    #[grammar(i8($v0))]
    I8(i8),
    #[grammar(i16($v0))]
    I16(i16),
    #[grammar(i32($v0))]
    I32(i32),
    #[grammar(i64($v0))]
    I64(i64),
    #[grammar($v0)]
    Bool(bool),
    #[grammar(usize($v0))]
    Usize(usize),
    #[grammar(isize($v0))]
    Isize(isize),
}


#[term($name $<parameters> { $,values })]
pub struct RigidConstData {
    pub name: RigidName,
    pub parameters: Parameters,
    pub values: Vec<Const>,
}

i.e., a const value can be a scalar value (as today) or a struct literal like Foo { ... } (which would also cover tuples and things). We got the various tests passing. Huzzah!

Boxy — comment from 2026-01-30
In addition to what niko posted previously there's been a lot of other stuff happening. A lot of people have opened PRs to improve mGCA this month: León Orell Valerian Liehr Noah Lev @enthropy7 Kivooeo mu001999 @Human9000-bit Redddy @Keith-Cancel @AprilNEA

A rough list of things that have been improved for mGCA:
- Lots of new expressions now supported by mGCA: const constructors, tuple constructor calls, array expressions, tuple expression, literals
- associated_const_equality has been merged into min_generic_const_args. the former was effectively dependent on the latter already so this just makes it nicer to use the former :)
- traits can now be dyn compatible if all associated constants are type consts and are specified in the trait object (e.g. dyn Trait<ASSOC = 10>)
- type consts are enforced to be non-generic
- a bunch of ICEs have been fixed
- camelid has been working on "non-min" version of mGCA which will allow arbitrary expressions to be used in the type system (a blog post with more detail will be published once this actually lands)
In non-mGCA updates, as niko says, we've been meeting regularly to make progress on modelling const generics in a-mir-formality. I've also been spending time thinking about the interactions between adt_const_params and ADTs with privacy/safety invariants and I think I know how to structure the RFC in this area so can make progress on that again

There's some more detail about the various bits of work people have done and who did what here: #project-const-generics > perfectly adequately sized wins @ 💬
Niko Matsakis — comment from 2026-02-13

Boxy and I have met (and continue to meet) and work on modeling const generics in a-mir-formality. We're still working on laying the groundwork.

There is a proposed project goal for next year.
Boxy — comment from 2026-02-28

There's been a lot of miscellaneous fixes for mGCA this month. I've also started drafting some blog posts to explain what's going on with mGCA/oGCA as well as soliciting use cases/experience reports for them and adt_const_params. I also talked with some folks at Rust Nation this month about const generics and what features would be useful for them and why.
Boxy — comment from 2026-04-02

Late on the update :') niko and i continue to meet to discuss const generics. we've made some progress on figuring out problems around privacy/safety in const generics. we've also been discussing the big picture stuff for const generics and where we're "heading".
Boxy — comment from 2026-05-01

started running weekly meetings about const generics to make it easier to keep up to date with all the people who are working on const generics stuff. i think min_adt_const_params is now at the point of what the RFC is going to specify.

GCA is making good progress thanks to ashley's work. i also met with lcnr where we talked about whether there was some version of mGCA that is stabilizeable in the near future or not (maybe!)

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

People involved: Predrag Gruevski
Champions: cargo (Ed Page), rustdoc (Alona Enraght-Moony)
Status: Continued

1 detailed update available.

Predrag Gruevski — comment from 2026-01-17

I posted a "year in review" for cargo-semver-checks.

It has a section on how I think we should move forward in 2026 and beyond.

Develop the capabilities to keep the FLS up to date

People involved: Pete LeVasseur, t-spec, and contributors from Ferrous Systems
Champions: bootstrap (Jakub Beránek), lang (Niko Matsakis), spec (Pete LeVasseur)
Status: Superseded by the Stabilize FLS Release Cadence 2026 goal

2 detailed updates available.

Pete LeVasseur — comment from 2026-03-04

We have a Project Goal in 2026 that we'll take on: Stabilize FLS Release Cadence. Progress towards 1.93.1 looks good, most issues are closed.

Help wanted

We'd love more folks from the safety-critical community to contribute to picking up issues or opening an issue if you notice something is missing.
Pete LeVasseur — comment from 2026-04-02
Trying to prepare FLS releases earlier:
- since we completed the 1.94.0 release of the FLS a bit early this time, we checked into the stretch part of our goal this year to look at 1.95.0 early
- we learned a bit more of the release notes process thanks to tips from Eric Huss and TC
- Tshepang Mbambo and I attended the t-release meeting last week where we chatted about working a little "upstream" with them on generating the release notes a bit earlier
- tomorrow in our t-fls meeting we'll discuss our interest with engaging over there; at a minimum I'll get engaged with t-release
Glossary and main-body text harmonization:
- the first PR landed from Tshepang Mbambo removing IDs from the glossary
- further steps planned, we have a tracking issue for it
Developer guide:
- akin to how the Reference now has a developer's guide now for contributing we'll do the same in the FLS
- Hristian Kirtchev has been working on this

Emit Retags in Codegen

People involved: Ian McCormack
Champions: compiler (Ralf Jung), opsem (Ralf Jung)
Status: Superseded by the BorrowSanitizer 2026 goal

4 detailed updates available.

Ian McCormack — comment from 2026-01-09
Here's our January status update!
- Yesterday, we posted an MCP for our retag intrinsics. While that's in progress, we'll start adapting our current prototype to remove our dependence on MIR-level retags. Once that's finished, we'll be ready to submit a PR.
- We published our first monthly blog post about BorrowSanitizer.
- Our overall goal for 2026 is to transition from a research prototype to a functional tool. Three key features have yet to be implemented: garbage collection, error reporting, and support for atomic memory accesses. Once these are complete, we'll be able to start testing real-world libraries and auditing our results against Miri.
Ian McCormack — comment from 2026-02-24
We just posted our February status update for BorrowSanitizer. TL;DR:
- We provide detailed error messages for aliasing violations, which look almost like Miri's do!
- We have two forms of retag intrinsic: __rust_retag_mem and __rust_retag_reg. We no longer require a compiler plugin to determine the permission associated with a retag, which will make it possible to use BorrowSanitizer by providing a single -Zsanitizer=borrow flag to rustc. You can check out our MCP for more detailed design updates.
- We are starting to have a better understanding of how BorrowSanitizer performs in practice, but we do not have enough data yet to be certain. From one test case, it seems like we are somewhat faster but still in the same category of performance as Miri when we compare against other sanitizers. Expect more detailed results to come as we scale up our benchmarking pipeline.
- We have a tentative plan for upstreaming BorrowSanitizer in 2026, starting with its LLVM components. We intend to start the RFC process on the LLVM side this spring, once our API is stable.
Ian McCormack — comment from 2026-03-30
We just posted our March status update for BorrowSanitizer. TL;DR:
- We added hundreds more relevant tests from Miri's test suite. At the moment, 80% pass.
- We improved our cargo plugin (cargo-bsan) to better support multilanguage libraries. This will let us start to recreate the bugs from our earlier evaluation.
Our goal for April is to continue expanding our test suite, finish an initial version of the LLVM components of BorrowSanitizer, and hopefully start the RFC process on the LLVM side.
Ian McCormack — comment from 2026-04-29
We have some exciting news: our talk on BorrowSanitizer was accepted at RustConf this year! We’re grateful for the opportunity and looking forward to sharing our results with the broader community this September.

We just posted our April status update. It’s a bit of a technical one. Here’s the TL;DR:
- BorrowSanitizer now uses a shadow stack to track metadata at runtime - this is a significantly different strategy than other LLVM sanitizers, and it will help us support garbage collection.
- We are now ready to start sending in PRs for our retag intrinsics. It will take a little time to split our changes up into meaningful, reviewable chunks—you can expect to see these throughout the next week.
The RFC for our LLVM components is taking a little longer than expected, but it was worth taking the extra time to test out compiler changes and make sure that we had the core parts of the instrumentation pass settled. We’ll be drafting the RFC throughout the next few weeks.

Expand the Rust Reference to specify more aspects of the Rust language

People involved: Josh Triplett, Amanieu d'Antras, Guillaume Gomez, Jack Huey, lcnr, Mara Bos, Vadim Petrochenkov, Jane Lusby
Champions: lang-docs (Josh Triplett), spec (Josh Triplett)
Status: Superseded by the Experimental language specification 2026 goal

1 detailed update available.

Josh Triplett — comment from 2026-04-14

This work is now continuing into a new goal by Jack Huey.

Finish the libtest json output experiment

People involved: Ed Page
Champions: cargo (Ed Page)
Status: Continued

Finish the std::offload module

People involved: Manuel Drehwald, LLVM offload/GPU contributors
Champions: compiler (Manuel Drehwald), lang (TC)
Status: Superseded by the High-Level ML optimizations 2026 goal

2 detailed updates available.

Manuel Drehwald — comment from 2026-01-16
std::autodiff is moving closer to nightly, and std::offload is gaining various performance, feature, and hardware support improvements.

autodiff

Jakub Beránek, sgasho, and I continued working on enabling autodiff in nightly. We have a PR up that builds autodiff in CI, and verified that the artifacts can be installed and work on Linux. For apple however, we noticed that any autodiff usage hangs. After some investigation, it turns out that we ended up embedding two LLVM copies, one in rustc, and one in Enzyme. It should be comparably easy to get rid of the second one. Once we verified that this fixes the build, we'll merge the PR to enable autodiff on both targets in nightly.

offload

A lot of interesting updates on the performance, feature, and hardware support side.
1. Marcelo Domínguez, @kevinsala, @jdoerfert, and I started implementing the first benchmarks, since that's generally the best way to find missing features or performance issues. We were positively surprised by how good the out-of-the-box performance was. We will implement a few more benchmarks and post the results once we have verified them. We also implemented multiple PRs which implement bugfixes, cleanups, and needed features like support for scalars. We also started working on LLVM optimizations which make sure that we can achieve even better performance.
2. I noticed that our offload intrinsic allowed running Rust code on the GPU, but it wasn't of much help when calling gpu vendor libraries like cuBLAS. I implemented a new helper intrinsic which allows calling those functions conveniently, without having to manually move data to or from the device. It will benefit from the same LLVM optimizations as our full offload intrinsic. It also a bit simpler to set up on the compiler and linker side, so it already works with std and mangled kernel names, something that we still have to improve for our main offload intrinsic.
3. A lot of work happened on the LLVM offload side for SPIRV and Intel GPU support. At the moment, our Rust frontend is tested on NVIDIA and AMD server and consumer GPUs, as well as AMD HPC and Lapotop APUs. Karol Zwolak reached out since he wants to help with with also running Rust on Intel GPUs. Offload relies on LLVM which started gaining Intel support, so hopefully we won't need much work beyond a new intel-gpu target and a new stdarch module. There is also work on a new spirv target for rustc, which we could also support if it goes through LLVM. Due to some open questions around typed pointers it does not seem clear yet whether it will, so we will have to wait.
4. Nikita started working on updating our submodule to LLVM 22. This hopefully does not only brings some compile and runtime performance improvements, but also greatly simplifies how we can build and use offload. Once it landed I'll refactor our bootstrapping logic, and as part of that start building offload in CI.
Manuel Drehwald — comment from 2026-04-01

std::autodiff is now partly in CI, and std::offload got tested on a lot more benchmarks.

autodiff

Work continued on enabling autodiff in nightly. Since the last update, we have enabled autodiff in some Mingw and Linux runners. Users can now download libEnzyme artifacts, place them locally in the right spot for their toolchain, and then use autodiff on their nightly compiler. Once macOS is added, we will enable a new rustup component that will handle the download for users. Before enabling autodiff on macOS, however, we want to change how we distribute LLVM on this target (from static to dynamic linking). There are a lot of workflows and users of this target, not all of which can be modelled in the Rust CI. Our last two attempts sadly broke such downstream users and local contributors, so both attempts had to be reverted. Since testing here is tricky, progress here might be on the slower side; we will see.

offload

Most of the work on the offload side lately has been invisible, since we were working on implementing more benchmarks and LLVM optimizations, as well as missing features, discovered by those benchmarks. We achieved excellent performance on those benchmarks; more details will soon be presented by Marcelo Domínguez at the EuroLLVM conference in two weeks!

Beyond benchmarks, there was a lot of tinkering on smaller PRs, reviewing, and housekeeping. LLVM-22 landed, so we updated our bootrstrap code to make use of new APIs, and tried to move a few smaller PRs forward, mainly around a better user experience and for making more Rust features available. Since the focus is still on benchmarks, not many of those PRs landed. They are in a mostly ready state, so it's a good time to pick them up if you're considering contributing. Please ping me on Zulip or in any PR with the offload label if you are interested!

Getting Rust for Linux into stable Rust: compiler features

People involved: Tomas Sedovic, compiler contributors
Champions: compiler (Wesley Wiser)
Status: Continued

4 detailed updates available.

Tomas Sedovic — comment from 2026-01-16

Update from the 2026-01-14 meeting:

#![register_tool] rust#66079

Tyler Mandry proposed FCP of the RFC#3808 and nominated it for a Lang discussion.

-Zdebuginfo-compression rust#120953

Wesley Wiser proposed stabilization: rust#150625.

Josh Triplett suggested trying to bring zlib-rs in the kernel as a case study.

-Zdirect-access-external-data rust#127488

rust#150494 was merged two days ago, what reminds is updating the documentation and stabilizing the feature.

There's an ongoing discussion about the feature on the Rust Zulip as well.
Tomas Sedovic — comment from 2026-02-17

Updates from the 2026-01-28 and 2026-02-11 meetings:

-Zdirect-access-external-data rust#127488

Gary Guo's fix PR was merged.

--emit=noreturn

Miguel Ojeda reiterated that this is high on the list of compiler features the project needs. Right now, they're doing these checks manually.

Improving objtool's handling of noreturn is on Gary Guo's radar but there wasn't time yet.
Tomas Sedovic — comment from 2026-03-16

Update from the 2026-03-11 meeting:

--emit=noreturn

It seems that figuring out which functions are noreturn is at a level too low for rustc. Function signatures are not sufficient and there are cases where rustc doesn't know whether to emit noreturn. It is something we should ask the LLVM to give us that information.

-Zsanitizer=kernel-hwaddress

Alice Ryhl opened a new issue to introduce the -Zsanitizer=kernel-hwaddress sanitizer for aarch64 targets: https://github.com/rust-lang/compiler-team/issues/975

-Zharden-sls

Wesley Wiser is working on allowing forbidden target features to be hard errors, which the -Zharden-sls patch should be rebased on top of.

#![register_tool]

The corresponding RFC has been discussed by the Lang team on 2026-03-11. The overall vibe was positive and TC is going to read through it and hopefully check a box on the proposed FCP.

-Zdebuginfo-compression

The proposed stabilization received some feedback that needs to be addressed.

-Zdirect-access-external-data

The discussion here has stalled.
Tomas Sedovic — comment from 2026-04-10

Update from the 2026-04-08 meeting:

-Zsanitize=kernel-hwaddress

rust#153049 is merged. What remains of the tracking issue rust#154171 is a few docs checklists.

Alice Ryhl added the unstable book doc changes in the PR itself and Wesley Wiser confirmed that's all the documentation needed for sanitizers.

Getting Rust for Linux into stable Rust: language features

People involved: Tomas Sedovic, Ding Xiang Fei
Champions: lang (Josh Triplett), lang-docs (TC)
Status: Superseded by the Rust for Linux 2026 roadmap

6 detailed updates available.

Tomas Sedovic — comment from 2026-01-19

Update from the 2026-01-14 meeting.

Deref / Receiver

Ding's arbitrary_self_types: Split the Autoderef chain rust#146095 is waiting on reviews. It updates the method resolution to essentially: deref_chain(T).flat_map(|U| receiver_chain(U)).

The perf run was a wash and a carter has completed yesterday. Analysis pending.

RFC #3851: Supertrait Auto-impl

Ding has submitted a Rust Project goal for Supertrait Auto Impl.

Arbitrary Self Types rust#44874

We've discovered the #[feature(arbitrary_self_types_pointer)] feature gate. As the Lang consensus is to not support the Receiver trait on raw pointer types we're probably going to remove it (but this needs further discussion). This was a remnant from the original proposal, but the Lang has changed direction since.

derive(CoercePointee) rust#123430

Ding is working on a fix to prevent accidental specialization of the trait implementation. rust#149968 is adding an interim fix.

Alice opened a Reference PR for rust#136776. There are questions around the behaviour of the as cast vs. coercions.

Pass pointers to const in assembly rfc#3848

Gary opened implementation for the RFC: rust#138618.

Field Projections goal#390

Benno updated the Field Representing Types PR to the latest design. This makes the PR much simpler.

Tyler opened a Beyond References wiki to keep all the proposals, resources in one place.

In-place initialization goal#395

Ding is writing a post to describe all the open proposals including Alice's new one that she brouhght up during the LPC 2025. He'll merge it in the Beyond References wiki.

Macros, attributes, derives, etc.

Josh brought up his work on adding more capable declarative macros for writing attributes and derives. He's asked the Rust for Linux team for what they need to stop using proc macros.

Miguel noted they've just added dependency on syn, but they would like to remove it some day if their could.

Benno provided a few cases of large macros that he thought were unlikely to be replaceable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion.
Tomas Sedovic — comment from 2026-02-16

Updates from the 2026-01-28 and 2026-02-11 meetings:

Removing the likely/unlikely hints in favour of cold_path

The stabilization of core::hint::cold_path lint is imminent and after it, the likely and unlikely hints are likely (pardon the pun) to be removed.

The team discussed the impact of this. These hints are used in C but not yet in Rust. cold_path would be sufficient, but likely/unlikely would still be more convenient in cases where there isn't an else branch. Tyler Mandry mentioned that these can be implemented in terms of cold_path.

Niche optimizations

We discussed the feasibility of embedding data in lower bits of a pointer -- something the kernel is doing in C. This could also enable setting the top bit in the integers (which is otherwise never set) and make it represent an error in that case (and a regular pointer otherwise).

Ideally, this would be done in safe Rust, as the idea is to improve the safety of the C code in question.

Extending the niches is something Rust wants to see, but it's waiting on pattern types. There are short/medium-term options by using unsafe and wrapping it in a safe macro, but the long-term hope is to have this supported in the language.

Vendoring zerocopy

The project has interest in vendoring zerocopy. We had its maintainers Jack Wrenn and Joshua Liebow-Feeser join us to discuss this and answer our questions. The main question was about whether to vendor at all, how often should we (or will have to) upgrade, and how much of it is expected to end up in the standard library.

The project follows semver with the extended promise to not break minor versions even before 1.0.0. We could vendor the current 0.8 and we should be upgrade on our own terms (e.g. when we bring in new features) rather than being forced to.

Right now, the project is able to experiment with various approaches and capabilities. Any stdlib integration a long way away, but there is interest in integrating these to the language and libraries where appropriate.

New trait solver

There's been a long-term effort to finish the new trait solver, which will unblock a lot of things. Niko Matsakis asked about things it's blocking for Rust for Linux.

This is the list: unmovable types, guaranteed destructors, Type Alias Impl Trait (TAIT), Return Type Notation (RTN), const traits, const generics (over integer types), extern type.

2026 Project goals

This year brings in the concept of roadmaps. We now have a Rust for Linux and a few more granular Goals. We'll be adding more goals over time, but the one merged cover what we've been focusing on for now.
Tomas Sedovic — comment from 2026-03-11

Update from the 2026-02-25 meeting:

2026 Project goals

We spent most of the meeting going over the open Project goals, the Rust for Linux roadmap and other things we'd like to see that aren't the right shape for a goal.

Miguel Ojeda brought up the upcoming Debian 14 release (coming out probably somewhere around Q2 of 2027) and we went over each item and decided whether it's something we need to make sure is in that release or not.

Debian stable is an important milestone and the Rust version in it serves as a baseline for Rust for Linux development.

I'll add all this data into the roadmap.
Tomas Sedovic — comment from 2026-03-16

Update from the 2026-03-11 meeting:

Field projections

We now have a macro and machinery that uses the projection mechanism.

The dma_read! / dma_write! macros switched over to it. This also fixes a soundness issue 1.

Note: this is done entirely via macros and doesn't use any Field projections language features. The Field projection syntax and traits should make this more ergonomic and integrate the borrow checker so we can accept more code.

We're planning to have a design meeting with the Lang team in the last week of March.

rustfmt imports formatting and trailing slashes

We talked about the rustfmt formatting of the use statements again. While the trailing empty comment // workaround (see this update) is acceptable as a temporary measure, we need to find a long-term solution where you can configure rustfmt to accept this style.

We don't have a issue for this specific formatting yet, though it was discussed in #3361.

The next step are to create such an issue. We were hesitant to add burden to a team that's already at limit, but having the issue would let us track it from the Rust for Linux side.
Tomas Sedovic — comment from 2026-03-26
Update from the 2026-03-26 meeting:

Const generics

Boxy asked the team for features that are most important under the const generics umbrella. This might help with prioritisation and just understanding of practical uses.
1. Ability to do arithmetic on const generic types: e.g. the kernel has a type Bounded which has a value and a maximum size (in bits). Both the bit width and value are const values. They want to be able to do arithmetics on these types (starting with bit shifts) that will guarantee the the result will fit within the specified size at compile time.
2. Argument-position const generics: right now, the const generic types must be specified in the type bound section (within the angle brackets). So for example you have to write: Bounded::<u8, 4>::new::<7>() instead of the more natural Bounded::<u8, 4>::new(7). This gets more complicated when there's const-time calculation happening rather than just a numerical constant -- in which case this also needs to be wrapped in curly brackets: { ... }.
3. Being generic over types other than numbers: pointers would be useful for asm_const_ptr. String literals too -- even if they're just passed through without being processed / operated on. And if going from a passthrough string makes it possible to pass through any type, that would help the team replace some typestate patterns they're using with an enum.
statx

Alice Ryhl proposed being able to create std::fs::Metadata from Linux statx syscall.

This was discussed in the Libs-API meeting and they had questions about possible evolutions of the statx ABI -- if/how it can grow in the future and how they could handle that if they wanted some of the new data available. So we discussed it in the Rust for Linux meeting.

In the end, it seems prudent to be reasonably defensive rather than relying on the syscall pre-filling default values.

Alice Ryhl proposed an opaque statx struct that would give the stdlib a way to decide on the struct's size, pre-filled contents and mask.

Miguel Ojeda suggested contacting Christian Brauner and Alexander Viro (i.e. the VFS maintainers); Josh Triplett agreed that it would be good if we can get a thread with the right people in linux-fsdevel.
Tomas Sedovic — comment from 2026-04-10

Update from the 2026-04-08 meeting:

zerocopy features in Rust's std

zerocopy uses two traits that are both polyfills for unstable traits : KnownLayout (for ptr_metadata) and Immutable (for Freeze). It would help maintenance of zerocopy (which Rust for Linux plans to start using) if these were stabilised.

ptr_metadata is something the team wants in the kernel independently. It's possibly blocked on (or at least might have interactions with) the Sized Hierarchy work.

Freeze (now NoCell) has an RFC.

Deref/Receiver

Jack Huey started reviewing Ding Xiang Fei's PR to split the autoderef chain and feels it's not ready to go in front of the full Lang team.

We also discussed the dependence/independence of the Deref and Receiver implementations, in particular whether it ever makes sense to implement Deref but not Receiver. Josh Triplett suggested gathering examples for cases like that (where you can't use the type as a Self type in the function declaration, but allow calling methods on it).

The current plan for the experiment is to have these traits separate, but have the compiler enforce that if they implement the same type, their targets are identical. This will let us open the door for any future possibilities (a supertrait / subtrait relation, or having diverging targets in the future).

We want to experiment to see where and how these traits and their possible evolution might be helpful.

null-ptr-deref

The team would like to have a (an optional) compiler guarantee, that the compiler never removes null checks on raw pointers. What can currently happen in C is that if you deref a null pointer, the compiler can do optimisations including removing any subsequent checks whether that pointer is null, because dereferencing a null pointer is undefined behaviour.

But the null check can still help prevent further bugs and in C, the kernel now disables the optimisation that would remove it.

Miguel Ojeda is going to open an MCP for this.

In-Place Initialization

Benno Lossin opened a proposal for an in-person room at the 2026 All Hands for In-place initialization.

Here's a meta issue tracking all the proposals and discussions about the feature.

The design space is complex and the team hopes that discussing it in person will help move it forward.

Implement Open API Namespace Support

People involved: Ed Page, b-naber
Champions: cargo (Ed Page), compiler (b-naber), crates-io (Carol Nichols)
Status: Continued

MIR move elimination

People involved: Amanieu d'Antras
Champions: lang (Amanieu d'Antras)
Status: Continued

1 detailed update available.

Amanieu d'Antras — comment from 2026-04-03
The RFC has just been published. It has been significantly reworked since the last draft.

Notable changes:
- Removed the concept of activation/de-activation. Now the semantics don't need to deal with partially allocated locals. This is less powerful optimization-wise but should still cover most cases.
- Added byref/byval to call arguments to clarify how they are passed.
- Added a separate section for the surface language changes to separate it from the MIR changes.
- Added more details on the MIR optimization which eliminates moves.
- Changed the MIR operand evaluation order to be left-to-right, except for destination places which are always evaluated last.
- Added StorageLive back: we need it to mark the location where llvm.lifetime.start should be inserted, which is not the same as the location where a local is initialized. In the opsem, StorageLive doesn't actually allocate the local, that's still done when it is initialized by a write.

Prototype a new set of Cargo "plumbing" commands

People involved: Ed Page
Champions: cargo (Ed Page)
Status: Continued

Prototype Cargo build analysis

People involved: Weihang Lo
Champions: cargo (Weihang Lo)
Status: Completed

1 detailed update available.

Weihang Lo — comment from 2026-01-08
The prototype of this project goal is basically complete.

Current state

This project goal introduces build analysis support in Cargo, with the aim of making build behavior understandable across multiple invocations, not just a single run.

At a high level, the prototype:
- Records build metadata over time, including:
  - rebuild reasons
  - timing information
  - relevant invocation context
- Stores this data locally in a structured log format suitable for later analysis
- Exposes the data via unstable cargo report subcommands, such as:
  - cargo report sessions - list session IDs
  - cargo report timings - HTML timing report
  - cargo report rebuilds - Why things rebuilt
See the Reference for a more thorough usage documentation

Path towards stabilization

Before this feature can be stabilized, the following unresolved questions must be answered. They might not block stabilization, but need to be evaluated if it is fine to leave for future.

cargo report commands

This is a stabilization blocker.
- Currently all three report commands (sessions, rebuilds, timings) implicitly inspect global log files when if not in a workspace.
  - Should this be explicit with a flag?
  - Should this be an error if not in a workspace?
- Bikeshed on command names
  - Currently we have all nouns
    - For sessions
      
      runs simple but ambiguous
      
      Just log like git log
      
      history user-friendly (docker history, shell history, though not alike)
    - For timings:
      
      Not controversial, as we have --timings flag already
    - For rebuilds:
      
      rebuild-reasons more explicit
  - Or move to action-oriented verbs:
  - cargo report list-sessions
  - cargo report analyze-timings (bazel analyze-profile)
  - cargo report explain-rebuilds
  - Or question-oriented verbs:
  - cargo report what-ran more general (buck2 log what-ran)
  - cargo report why-rebuilt/why-reran
cargo report sessions
- Currently it prints a human-readable output without a format for programmable use cases.
  - Should we provide a programmable output (for example behind --message-format=json)?
cargo report rebuilds
- Extend the report from fingerprint to new hash (-Cmetadata/-Cextra-filename)
  - We currently can't distinguish whether a fresh build is a real new build or just rustflags changed
  - https://github.com/rust-lang/cargo/pull/16456#discussion_r2662364819
- Make each rebuilt reason more actionable and friendly for end-users.
- Should we log the fingerprint values being compared, or just the diff result?
- #t-cargo > logging unit fingerprint @ 💬
Log message schema

This is a stabilization blocker.
- Providing types for reading log messages
  - We should export LogMessage enum and related types in cargo-util-schemas
  - Users may want to parse logs programmatically
  - https://github.com/rust-lang/cargo/pull/16150#discussion_r2462065538
- JSON schema evolution and versioning
  - Should we version the schema explicitly in each message?
  - Compatibility might be the same as https://doc.rust-lang.org/nightly/cargo/commands/cargo-metadata.html?highlight=compa#compatibility
- Message structure consistency
  - Current log messages deviate from cargo's normal JSON message structure
  - Should we align with existing cargo JSON output format, for example the target field?
  - https://github.com/rust-lang/cargo/pull/16414#discussion_r2632724893
  - https://github.com/rust-lang/cargo/pull/16303#discussion_r2565526807
  - https://github.com/rust-lang/cargo/pull/16303#discussion_r2561862478
- Should we expose the entire DirtyReason enum as-is?
  - Currently exposes internal implementation details
  - May want to create a separate public-facing enum
  - Need to decide which variants are user-facing vs internal
- Check usefulness of each variant
  - Some variants may be obsolete (e.g., RustflagsChanged may be rare after -Cmetadata changes)
  - Need audit of which variants actually occur in practice
  - Remove or consolidate rarely-used variants
- Make dirty reasons end-user friendly
  - Current reasons are technical (e.g., "local fingerprint type changed")
  - Users need actionable messages (e.g., "file modified: src/lib.rs")
- Expose target and mode
  - Are they universal for all kind of units? We might want to rename mode to action, as an action kind of a unit.
  - https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20analysis.20log.20format/near/564781487
Log infrastructure

These are mostly future possibilities, not a stabilization blocker, as it is highly possible to do incremental improvements.
- log compression https://github.com/rust-lang/cargo/issues/16475
- log rotation https://github.com/rust-lang/cargo/issues/16471
- Is losing data on crashes ok? https://github.com/rust-lang/cargo/pull//16150#discussion_r2462056940
See also https://github.com/rust-lang/cargo/issues/16471#issuecomment-3724915770

Nested Cargo calls

See https://github.com/rust-lang/cargo/issues/16477.

Basically, we need to have a way to associate log files of nested Cargo calls. That helps other tools as well as cargo fix itself.

This is a stabilization blocker.

How contributors can help

Future contributors can help by:
- picking up any linked issues below or in https://github.com/rust-lang/cargo/issues/15844
- building external tools utilizing the log messages, and providing feedback
- providing real-world feedback from large or unusual builds
A series of follow-up tasks has been cut to track remaining work:
- https://github.com/rust-lang/cargo/issues/16470
- https://github.com/rust-lang/cargo/issues/16471
- https://github.com/rust-lang/cargo/issues/16472
- https://github.com/rust-lang/cargo/issues/16473
- https://github.com/rust-lang/cargo/issues/16474
- https://github.com/rust-lang/cargo/issues/16475
- https://github.com/rust-lang/cargo/issues/16477
- https://github.com/rust-lang/cargo/issues/16488

reflection and comptime

People involved: Oliver Scherer
Champions: compiler (Oliver Scherer), lang (Scott McMurray), libs (Josh Triplett)
Status: Continued

5 detailed updates available.

Oliver Scherer — comment from 2026-01-14
- The MVP has landed, and we even got the first contribs adding array support to reflection.
  - there are lots more types and type information that we could support, and it's rather easy to add more. Happy to review any work here.
- try_as_dyn and try_as_dyn_mut have landed, and I'm working on removing the 'static requirement.
Oliver Scherer — comment from 2026-02-09
- @BD103 added Type::of for unsized types and support for slices, arrays, and raw pointer
- Asuna added all of our primitives
- Jamie Hill-Daniel gave us references
- @izagawd made it possible to extract some info from dyn Trait
There is ongoing work for Adts and function pointers, both of which will land as MVPs and will need some work to make them respect semver or generally become useful in practice

Removing the 'static bound from try_as_dyn turned out to have many warts, so I'm limiting it to a much smaller subset and will have borrowck emit the 'static requirement if the other rules do not apply (instead of having an unconditional 'static requirement)
Oliver Scherer — comment from 2026-03-19
- I added support for getting reflection information of any type, not just 'static ones
- 9SonSteroids added a function pointer MVP and trait object support
- Asuna added basic struct/enum/union support
Oliver Scherer — comment from 2026-04-22

No changes since last time.

I'm writing a document for the lang team meeting on reflection next week
Oliver Scherer — comment from 2026-04-22
Help wanted
- add more information to adts (e.g. doc comments, attributes, ...), whatever else is usually used by crates like bevy-reflect
- need to make struct field reflection respect privacy

Rework Cargo Build Dir Layout

People involved: Ross Sullivan
Champions: cargo (Weihang Lo)
Status: Completed; the Cargo cross workspace cache 2026 goal will build on this work

2 detailed updates available.

Ross Sullivan — comment from 2026-01-15

Fine grain locking for build-dir was merged and now available on nightly via -Zfine-grain-locking unstable flag. 🎉

There are some known issues we'd like to address before doing a formal call for testing. Notably, improving blocking messages, fixing potential thread starvation in Cargo's job queue when locks block, and investigate increasing rlimits to reduce risk of hitting max file descriptors for large projects.

I am hopeful that these issues will be resolved over the coming month and we can do a call for testing to start gathering feedback from the community on whether the new locking strategy improves workflows.
Ross Sullivan — comment from 2026-03-09

After the initial PR from the last update was merged, we shifted our focus to resolving some of the known issues. Notably, locking blocks the Cargo job queue slowly causing thread starvation if many build units are held by another Cargo instance.

We investigated adding the ability for Cargo to "suspend" a job internally while waiting for a lock, but we felt this change was a bit invasive and did not fit well with how the job queue was designed. Instead we plan to change our design to acquire all build unit locks prior to running the job queue (see #16657).

At the same time, we have continued to refine the new build-dir to prepare it for a call for testing and eventual stabilization. (#16542, #16502, #16515, #16514)

Finally we decided to split .cargo-lock into 2 locks to allow cargo check and cargo build to run in parallel when artifact-dir == build-dir (and -Zfine-grain-locking is enabled)

I suspect this may be the last update on this goal, as the 2026 slate of goals is coming up. While I did not renew this goal for 2026, I do plan to continue work on this and eventually stabilize this within this year.

Run more tests for GCC backend in the Rust's CI

People involved: Guillaume Gomez
Champions: compiler (Wesley Wiser), infra (Marco Ieni)
Status: Completed

Rust Stabilization of MemorySanitizer and ThreadSanitizer Support

People involved: Jakob Koschel, Bastian Kersting
Status: Continued

3 detailed updates available.

Jakob Koschel — comment from 2026-01-14

The MCP has been seconded and is still waiting 3 days to be approved. Once that is done, we can proceed with merging the Tier 2 target.
Jakob Koschel — comment from 2026-02-16

Both the MCP and the PR for the AddressSanitizer target have been merged. Next up I should prepare the MCP for the Memory- and ThreadSanitizer targets, hopefully sending out soon.
Jakob Koschel — comment from 2026-03-31

The targets for MSan and TSan are merged now.

Next, I'll be working on stabilizing those two, now that we have a way to use it without other unstable features (build-std).

Rust Vision Document

People involved: Niko Matsakis, vision team
Status: Partially completed; work continues outside of Project Goals

rustc-perf improvements

People involved: James Barford, Jakub Beránek, David Wood
Champions: compiler (David Wood), infra (Jakub Beránek)
Status: Technical work completed; remaining policy and infrastructure work postponed

Stabilize public/private dependencies

People involved: Ed Page
Champions: cargo (Ed Page)
Status: Continued

Stabilize rustdoc `doc_cfg` feature

People involved: Guillaume Gomez
Champions: rustdoc (Guillaume Gomez)
Status: Not completed (blocked)

SVE and SME on AArch64

People involved: David Wood
Champions: compiler (David Wood), lang (Niko Matsakis), libs (Amanieu d'Antras)
Status: Continued

5 detailed updates available.

David Wood — comment from 2026-01-15

rust-lang/rust#143924 has been merged, enabling scalable vector types to be defined on nightly, and I'm working on a patch to introduce unstable intrinsics/scalable vector types to std::arch
David Wood — comment from 2026-02-17

Progress has been slow since the last update because I've been busy, but I've been working on a rebase of rust-lang/stdarch#1509, which has bitrot quite a bit. Rémy Rakic is joining me to work on the Sized Hierarchy parts of the goal.
David Wood — comment from 2026-03-17

On the scalable vector half of the goal, I've got a branch with rust-lang/stdarch#1509 rebased, though without the intrinsic-test tool having been updated - that ended up being tricky and we've agreed to do it as a follow-up. We've opened rust-lang/rust#153286 with the compiler fixes that the stdarch patch requires, which should land soon (rust-lang/rust#153653 was opened and landed in the interim).

On the sized hierarchy half of the goal, Rémy Rakic has been updating our RFC such that we can discuss it in design meetings with the language team on the 18th and 25th - we'll update rust-lang/rfcs#3729 later today. We've split out the const Sized parts as a future possibility (though one we are committed to pursuing) as that has more open design questions, and we've discussed the proposed syntax and approach to migration - which are what we intend to focus on in the design meetings. He's also been working out how we can start implementing our migration strategy and help resolve blockers in other areas.
David Wood — comment from 2026-03-17

Per last comment, rust-lang/rfcs#3729 has been updated
David Wood — comment from 2026-04-14

For the scalable vector half of the goal, we've landed a bunch of compiler fixes - rust-lang/rust#153286, rust-lang/rust#153608, rust-lang/rust#154850, rust-lang/rust#154950, rust-lang/rust#155106 and rust-lang/rust#155243 - and opened our stdarch patch with intrinsics - rust-lang/stdarch#2071. That patch should be passing CI tomorrow once nightly updates to fix an unrelated spurious CI failure. We've got a handful of follow-ups to do afterwards, listed on rust-lang/rust#145052.

For the sized hierarchy half of the goal, Rémy Rakic and I had two design meetings with the language team (2026/03/18 and 2026/03/25) discussing the syntax/naming and migration strategy respectively.

On syntax, the language team preferred introducing an "only bounds" syntax to control opting-out of default bounds and opting-in to alternative bounds in a family of traits (described in an alternative in the RFC), but there was an open question of whether that syntax should apply to an individual bound or all of the bounds - Niko Matsakis is investigating that.

On naming, the language team also preferred the name SizeOfVal over MetaSized, and didn't like Pointee but had no better alternatives. Rémy Rakic prepared rust-lang/rust#154374 to do that renaming and started a discussion with the library team to confirm they were happy with the name, because changing it involves an amount of churn. The library team wanted to know what other traits in the hierarchy might later be introduced, as that would help inform the naming of the currently proposed traits, so Rémy Rakic wrote up a document with that information. We're holding off on doing any name changes until we find some consensus between libs and lang - who is responsible for these traits' names is a bit unclear.

On migration, the language team were largely happy with our proposed approach, and we realised that the approach proposed by lcnr for associated types might also work for our other migrations. Rémy Rakic has had meetings with lcnr to better understand that approach and to work out the next steps for implementing it.

Type System Documentation

People involved: Boxy, lcnr
Champions: types (Boxy)
Status: Continued

Unsafe Fields

People involved: Jack Wrenn, Jacob Pratt, Luca Versari
Champions: compiler (Jack Wrenn), lang (Scott McMurray)
Status: Continued

2 detailed updates available.

Jack Wrenn — comment from 2026-02-18

RFC has been accepted. I'm preparing a 2026 continuing goal for stabilization.
Jack Wrenn — comment from 2026-04-14

Opened PR (#16767(https://github.com/rust-lang/rust-clippy/pull/16767)) extending Clippy support to unsafe fields.

Blockers

Waiting for t-clippy to review #16767(https://github.com/rust-lang/rust-clippy/pull/16767).

Rust is participating in Outreachy

2026-05-04T00:00:00+00:00

The Rust Project has been building up a good history of participating in various open-source mentorship programs, including Google Summer of Code for three years (including this year) and previously OSPP. We're happy to announce that this year we are also participating in Outreachy starting in the May 2026 cohort.

Each of these mentorship programs has different criteria for eligibility depending on who they target and the motivations of the program. Outreachy provides internships in open source, to people from any background who face underrepresentation, systemic bias, or discrimination in the technical industry where they are living. You can learn more about the Outreachy program on their website.

What is Outreachy and how is it different than Google Summer of Code

Outreachy is similar to Google Summer of Code (GSoC) in some aspects, but different in others. First off, unlike GSoC, Outreachy interns first apply to the overall program and only then can apply to specific communities. Second, while oftentimes GSoC applicants submit various contributions prior to their application, Outreachy has a dedicated period where contributions are not just optional, but required. Finally, Outreachy applicants submit an application similar to GSoC applications and communities pick interns based on those applications and the interns' contributions. Outreachy has two internship periods per year, one running from May to August (in which we are currently participating) and one from December to March.

The other major difference between Google Summer of Code and Outreachy is the source of intern stipends. For GSoC, Google graciously covers contributor stipends and overhead. For Outreachy, communities instead cover the interns' stipends and overhead.

We are mentoring 4 interns for the May 2026 cohort

Because of limited funding availability and mentoring capacity, the Rust Project decided to select four interns for mentorship. We'll briefly share these projects below.

Calling overloaded C++ functions from Rust

Ajay Singh has been selected, mentored by teor, Taylor Cramer, and Ethan Smith.

This project aims to implement an experimental feature for calling overloaded C++ functions from Rust, and to begin testing that feature in a few representative use cases.

Code coverage of the Rust compiler at scale

Akintewe Oluwasola has been selected, mentored by Jack Huey.

This project aims to develop the workflows to run and analyze code coverage of the compiler at the scale of the entire compiler test suite and on ecosystem crates detected by crater. The hope is to be able to detect when the compiler is inadequately tested, both within the compiler and in the ecosystem, and to build tools to do continuous analysis on this.

Fuzzing the a-mir-formality type system implementation

Tunde-Ajayi Olamiposi has been selected, mentored by Niko Matsakis, Rémy Rakic, and tiif.

This project aims to implement fuzzing for a-mir-formality, an in-progress model for Rust's type and trait system. The goal is to generate programs in order to identify rules with underspecified semantics in a-mir-formality.

Improve the security of GitHub Actions of the Rust Project

oghenerukevwe Sandra Idjighere has been selected, mentored by Marco Ieni and Ubiratan Soares.

This project aims to improve the security of GitHub Actions workflows of the repositories owned by the Rust Project. It will develop tools and workflows, integrating with existing software, to analyze Github repositories and detect if they follow the best security practices, fix existing issues, and ensure that good security practices are followed in the future.

What's next

Over the next 3 months, the interns will work closely with their mentors to make progress on their projects. When the internship period is over, we'll write another blog post to share the results! See you then!

We also want to thank all the people that submitted applications and made contributions. It was quite tough to decide which applicants to select. Hopefully we will participate in Outreachy again in the future and there are other opportunities to participate. We also very much welcome you to stick around and continue being involved - there is a ton of places in the Rust Project with opportunities to be involved.

Raising the baseline for the `nvptx64-nvidia-cuda` target

2026-05-01T00:00:00+00:00

The nvptx64-nvidia-cuda target is a compilation target for NVIDIA GPUs. When using this target, the final output is PTX. Two version choices shape that output:

a GPU architecture (for example, sm_70, sm_80, …), which determines which GPUs can run the PTX, and
a PTX ISA version, which determines which CUDA driver versions can load (and JIT-compile) the PTX.

In Rust 1.97 (scheduled for release on July 9, 2026), the baseline PTX ISA version and GPU architecture for nvptx64-nvidia-cuda will be increased. These changes affect both the Rust compiler (rustc) and related host tooling, and they make it impossible to generate PTX artifacts compatible with older GPUs and older CUDA drivers.

The new minimum supported versions will be:

PTX ISA 7.0 (requires a CUDA 11 driver or newer)
SM 7.0 (GPUs with compute capability below 7.0 are no longer supported)

Why are the requirements being changed?

Until now, Rust has supported emitting PTX for a wide range of GPU architectures and PTX ISA versions. In practice, several defects existed that could cause valid Rust code to trigger compiler crashes or miscompilations. Raising the baseline addresses these issues and enables more complete support for the remaining supported hardware.

Removing support affects users of the architectures being removed. In this case, the most recent affected GPU architectures date back to 2017 and are no longer actively supported by NVIDIA. We therefore expect the overall impact of this change to be limited.

Maintaining support for these architectures would require substantial effort. These removals let us focus development efforts on improving correctness and performance for currently supported hardware.

What happens when I update to Rust 1.97?

If you need to target a CUDA driver that does not support PTX ISA 7.0 (CUDA 10-era drivers and older), Rust 1.97 will no longer be able to generate PTX compatible with that environment. Similarly, if you need to run on GPUs with compute capability below 7.0 (for example, Maxwell or Pascal), Rust 1.97 will no longer be able to generate compatible PTX for those GPUs.

Assuming you are targeting a CUDA driver compatible with CUDA 11 or newer and using GPUs with compute capability 7.0 or newer:

If you do not specify -C target-cpu, the new default will be sm_70, and your build should continue to work (but will no longer be compatible with pre-Volta GPUs).
If you currently specify an older -C target-cpu (for example, sm_60), you will need to either:
- remove that flag and let it default to sm_70, or
- update it to sm_70 or a newer architecture.
If you already specify -C target-cpu=sm_70 (or newer), there should be no behavioral changes from this update.

For more details on building and configuring nvptx64-nvidia-cuda, see the platform support documentation.

Announcing Google Summer of Code 2026 selected projects

2026-04-30T00:00:00+00:00

As previously announced, the Rust Project is participating in Google Summer of Code (GSoC) 2026. GSoC is a global program organized by Google that is designed to bring new contributors to the world of open source.

A few months ago, we published a list of GSoC project ideas, and started discussing these projects with potential GSoC applicants on our Zulip. We had many interesting discussions with the potential contributors, and even saw some of them making non-trivial contributions to various Rust Project repositories before GSoC officially started!

The applicants prepared and submitted their project proposals by the end of March. This year, we received 96 proposals, which is a 50% increase from last year. We are glad that there was again a lot of interest in our projects! Like many other GSoC organizations this year, we somewhat struggled with some AI-generated proposals and low-quality contributions generated using AI agents, but it stayed manageable.

GSoC requires us to produce an ordered list of the best proposals, which is always challenging, as Rust is a big project with many priorities. Our mentors examined the submitted proposals and evaluated them based on their prior interactions with the given applicant, their contributions so far, the quality of the proposal itself, but also the importance of the proposed project for the Rust Project and its wider community. We also had to take mentor bandwidth and availability into account. Unfortunately, we had to cancel some projects due to several mentors losing their funding for Rust work in the past few weeks.

As is usual in GSoC, even though some project topics received multiple proposals¹, we had to pick only one proposal per project topic. We also had to choose between proposals targeting different work to avoid overloading a single mentor with multiple projects. In the end, we narrowed the list down to the best proposals that we could still realistically support with our available mentor pool. We submitted this list and eagerly awaited how many of them would be accepted into GSoC.

Selected projects

On the 30th of April, Google has announced the accepted projects. We are happy to share that 13 Rust Project proposals were accepted by Google for Google Summer of Code 2026. That is a lot of projects! We are really happy and excited about GSoC 2026!

Below you can find the list of accepted proposals (in alphabetical order), along with the names of their authors and the assigned mentor(s):

A Frontend for Safe GPU Offloading in Rust by Marcelo Domínguez, mentored by Manuel Drehwald
Adding WebAssembly Linking Support to Wild by Kei Akiyama, mentored by David Lattimore
Bringing autodiff and offload into Rust CI by Shota Sugano, mentored by Manuel Drehwald
Debugger for Miri by Mohamed Ali Mohamed, mentored by Oli Scherer
Implementing impl and mut restrictions by Ryosuke Yamano, mentored by Jacob Pratt and Urgau
Improving Ergonomics and Safety of serialport-rs by Tanmay, mentored by Christian Meusel
libc: transition differing bit-width time and offset variants and deprecate bug-prone constants by Adam Martinez, mentored by Trevor Gross
Link Linux kernel and its Modules with Wild by Vishruth Thimmaiah, mentored by David Lattimore
Migrating rust-analyzer assists to SyntaxEditor by Shourya Sharma, mentored by Chayim Refael Friedman and Lukas Wirth
Port std::arch test suite to rust-lang/rust by Sumit Kumar, mentored by Jakub Beránek and Folkert de Vries
Reorganizing tests/ui/issues by zedddie, mentored by Teapot and Kivooeo
Utilize debugger APIs to improve debug info test accuracy and error reporting by Anthony Bolden, mentored by Jakub Beránek and Jieyou Xu
XDG path support for rustup by Guicheng Liu, mentored by rami3l

Congratulations to all applicants whose project was selected! Our mentors are looking forward to working with you on these exciting projects to improve the Rust ecosystem. You can expect to hear from us soon, so that we can start coordinating the work on your GSoC projects.

We are excited to mentor three contributors who already experienced GSoC with us in the previous year. Welcome back, Kei, Marcelo and Shourya!

We would like to thank all the applicants whose proposal was sadly not accepted, for their interactions with the Rust community and contributions to various Rust projects. There were some great proposals that did not make the cut, in large part because of limited mentorship capacity. However, even if your proposal was not accepted, we would be happy if you would consider contributing to the projects that got you interested, even outside GSoC! Our project idea list is still current and could serve as a general entry point for contributors that would like to work on projects that would help the Rust Project and the Rust ecosystem. Some of the Rust Project Goals are also looking for help.

There is a good chance we'll participate in GSoC next year as well (though we can't promise anything at this moment), so we hope to receive your proposals again in the future!

The accepted GSoC projects will run for several months. After GSoC 2026 finishes (in autumn of 2026), we will publish a blog post in which we will summarize the outcome of the accepted projects.

The most popular project topic received fourteen different proposals! ↩

Announcing Rust 1.95.0

2026-04-16T00:00:00+00:00

The Rust team is happy to announce a new version of Rust, 1.95.0. Rust is a programming language empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, you can get 1.95.0 with:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.95.0.

If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across!

What's in 1.95.0 stable

`cfg_select!`

Rust 1.95 introduces a cfg_select! macro that acts roughly similar to a compile-time match on cfgs. This fulfills the same purpose as the popular cfg-if crate, although with a different syntax. cfg_select! expands to the right-hand side of the first arm whose configuration predicate evaluates to true. Some examples:

cfg_select! {
    unix => {
        fn foo() { /* unix specific functionality */ }
    }
    target_pointer_width = "32" => {
        fn foo() { /* non-unix, 32-bit functionality */ }
    }
    _ => {
        fn foo() { /* fallback implementation */ }
    }
}

let is_windows_str = cfg_select! {
    windows => "windows",
    _ => "not windows",
};

if-let guards in matches

Rust 1.88 stabilized let chains. Rust 1.95 brings that capability into match expressions, allowing for conditionals based on pattern matching.

match value {
    Some(x) if let Ok(y) = compute(x) => {
        // Both `x` and `y` are available here
        println!("{}, {}", x, y);
    }
    _ => {}
}

Note that the compiler will not currently consider the patterns matched in if let guards as part of the exhaustiveness evaluation of the overall match, just like if guards.

Stabilized APIs

MaybeUninit<[T; N]>: From<[MaybeUninit<T>; N]>
MaybeUninit<[T; N]>: AsRef<[MaybeUninit<T>; N]>
MaybeUninit<[T; N]>: AsRef<[MaybeUninit<T>]>
MaybeUninit<[T; N]>: AsMut<[MaybeUninit<T>; N]>
MaybeUninit<[T; N]>: AsMut<[MaybeUninit<T>]>
[MaybeUninit<T>; N]: From<MaybeUninit<[T; N]>>
Cell<[T; N]>: AsRef<[Cell<T>; N]>
Cell<[T; N]>: AsRef<[Cell<T>]>
Cell<[T]>: AsRef<[Cell<T>]>
bool: TryFrom<{integer}>
AtomicPtr::update
AtomicPtr::try_update
AtomicBool::update
AtomicBool::try_update
AtomicIn::update
AtomicIn::try_update
AtomicUn::update
AtomicUn::try_update
cfg_select!
mod core::range
core::range::RangeInclusive
core::range::RangeInclusiveIter
core::hint::cold_path
<*const T>::as_ref_unchecked
<*mut T>::as_ref_unchecked
<*mut T>::as_mut_unchecked
Vec::push_mut
Vec::insert_mut
VecDeque::push_front_mut
VecDeque::push_back_mut
VecDeque::insert_mut
LinkedList::push_front_mut
LinkedList::push_back_mut
Layout::dangling_ptr
Layout::repeat
Layout::repeat_packed
Layout::extend_packed

These previously stable APIs are now stable in const contexts:

fmt::from_fn
ControlFlow::is_break
ControlFlow::is_continue

Destabilized JSON target specs

Rust 1.95 removes support on stable for passing a custom target specification to rustc. This should not affect any Rust users using a fully stable toolchain, as building the standard library (including just core) already required using nightly-only features.

We're also gathering use cases for custom targets on the tracking issue as we consider whether some form of this feature should eventually be stabilized.

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Contributors to 1.95.0

Many people came together to create Rust 1.95.0. We couldn't have done it without all of you. Thanks!

docs.rs: building fewer targets by default

2026-04-04T00:00:00+00:00

Building fewer targets by default

On 2026-05-01, docs.rs will make a breaking change to its build behavior.

Today, if a crate does not define a targets list in its docs.rs metadata, docs.rs builds documentation for a default list of five targets.

Starting on 2026-05-01, docs.rs will instead build documentation for only the default target unless additional targets are requested explicitly.

This is the next step in a change we first introduced in 2020, when docs.rs added support for opting into fewer build targets. Most crates do not compile different code for different targets, so building fewer targets by default is a better fit for most releases. It also reduces build times and saves resources on docs.rs.

This change only affects:

new releases
rebuilds of old releases

How is the default target chosen?

If you do not set default-target, docs.rs uses the target of its build servers: x86_64-unknown-linux-gnu.

You can override that by setting default-target in your docs.rs metadata:

[package.metadata.docs.rs]
default-target = "x86_64-apple-darwin"

How do I build documentation for additional targets?

If your crate needs documentation to be built for more than the default target, define the full list explicitly in your Cargo.toml:

[package.metadata.docs.rs]
targets = [
    "x86_64-unknown-linux-gnu",
    "x86_64-apple-darwin",
    "x86_64-pc-windows-msvc",
    "i686-unknown-linux-gnu",
    "i686-pc-windows-msvc"
]

When targets is set, docs.rs will build documentation for exactly those targets.

docs.rs still supports any target available in the Rust toolchain. Only the default behavior is changing.

Changes to WebAssembly targets and handling undefined symbols

2026-04-04T00:00:00+00:00

Rust's WebAssembly targets are soon going to experience a change which has a risk of breaking existing projects, and this post is intended to notify users of this upcoming change, explain what it is, and how to handle it. Specifically, all WebAssembly targets in Rust have been linked using the --allow-undefined flag to wasm-ld, and this flag is being removed.

What is `--allow-undefined`?

WebAssembly binaries in Rust today are all created by linking with wasm-ld. This serves a similar purpose to ld, lld, and mold, for example; it takes separately compiled crates/object files and creates one final binary. Since the first introduction of WebAssembly targets in Rust, the --allow-undefined flag has been passed to wasm-ld. This flag is documented as:

  --allow-undefined       Allow undefined symbols in linked binary. This options
                          is equivalent to --import-undefined and
                          --unresolved-symbols=ignore-all

The term "undefined" here specifically means with respect to symbol resolution in wasm-ld itself. Symbols used by wasm-ld correspond relatively closely to what native platforms use, for example all Rust functions have a symbol associated with them. Symbols can be referred to in Rust through extern "C" blocks, for example:

unsafe extern "C" {
    fn mylibrary_init();
}

fn init() {
    unsafe {
        mylibrary_init();
    }
}

The symbol mylibrary_init is an undefined symbol. This is typically defined by a separate component of a program, such as an externally compiled C library, which will provide a definition for this symbol. By passing --allow-undefined to wasm-ld, however, it means that the above would generate a WebAssembly module like so:

(module
    (import "env" "mylibrary_init" (func $mylibrary_init))

    ;; ...
)

This means that the undefined symbol was ignored and ended up as an imported symbol in the final WebAssembly module that is produced.

The precise history here is somewhat lost to time, but the current understanding is that --allow-undefined was effectively required in the very early days of introducing wasm-ld to the Rust toolchain. This historical workaround stuck around till today and hasn't changed.

What's wrong with `--allow-undefined`?

By passing --allow-undefined on all WebAssembly targets, rustc is introducing diverging behavior between other platforms and WebAssembly. The main risk of --allow-undefined is that misconfiguration or mistakes in building can result in broken WebAssembly modules being produced, as opposed to compilation errors. This means that the proverbial can is kicked down the road and lengthens the distance from where the problem is discovered to where it was introduced. Some example problematic situations are:

If mylibrary_init was typo'd as mylibraryinit then the final binary would import the mylibraryinit symbol instead of calling the linked mylibrary_init C symbol.
If mylibrary was mistakenly not compiled and linked into a final application then the mylibrary_init symbol would end up imported rather than producing a linker error saying it's undefined.
If external tooling is used to process a WebAssembly module, such as wasm-bindgen or wasm-tools component new, these tools don't know what to do with "env" imports by default and they are likely to provide an error message of some form that isn't clearly connected back to the original source code and where the symbols was imported from.
For web users if you've ever seen an error along the lines of Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../". this can mean that "env" leaked into the final module unexpectedly and the true error is the undefined symbol error, not the lack of "env" items provided.

All native platforms consider undefined symbols to be an error by default, and thus by passing --allow-undefined rustc is introducing surprising behavior on WebAssembly targets. The goal of the change is to remove this surprise and behave more like native platforms.

What is going to break, and how to fix?

In theory, not a whole lot is expected to break from this change. If the final WebAssembly binary imports unexpected symbols, then it's likely that the binary won't be runnable in the desired embedding, as the desired embedding probably doesn't provide the symbol as a definition. For example, if you compile an application for wasm32-wasip1 if the final binary imports mylibrary_init then it'll fail to run in most runtimes because it's considered an unresolved import. This means that most of the time this change won't break users, but it'll instead provide better diagnostics.

The reason for this post, however, is that it's possible users could be intentionally relying on this behavior. For example your application might have:

unsafe extern "C" {
    fn js_log(n: u32);
}

// ...

And then perhaps some JS code that looks like:

let instance = await WebAssembly.instantiate(module, {
    env: {
        js_log: n => console.log(n),
    }
});

Effectively it's possible for users to explicitly rely on the behavior of --allow-undefined generating an import in the final WebAssembly binary.

If users encounter this then the code can be fixed through a #[link] attribute which explicitly specifies the wasm_import_module name:

#[link(wasm_import_module = "env")]
unsafe extern "C" {
    fn js_log(n: u32);
}

// ...

This will have the same behavior as before and will no longer be considered an undefined symbol to wasm-ld, and it'll work both before and after this change.

Affected users can also compile with -Clink-arg=--allow-undefined as well to quickly restore the old behavior.

When is this change being made?

Removing --allow-undefined on wasm targets is being done in rust-lang/rust#149868. That change is slated to land in nightly soon, and will then get released with Rust 1.96 on 2026-05-28. If you see any issues as a result of this fallout please don't hesitate to file an issue on rust-lang/rust.

Announcing Rust 1.94.1

2026-03-26T00:00:00+00:00

The Rust team has published a new point release of Rust, 1.94.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of Rust installed via rustup, getting Rust 1.94.1 is as easy as:

rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website.

What's in 1.94.1

Rust 1.94.1 resolves three regressions that were introduced in the 1.94.0 release.

Fix std::thread::spawn on wasm32-wasip1-threads
Remove new methods added to std::os::windows::fs::OpenOptionsExt The new methods were unstable, but the trait itself is not sealed and so cannot be extended with non-default methods.
Clippy: fix ICE in match_same_arms
Cargo: downgrade curl-sys to 0.4.83 This fixes certificate validation error for some users on some versions of FreeBSD. See this issue for more details.

And a security fix:

Cargo: Update tar to 0.4.45 This resolves CVE-2026-33055 and CVE-2026-33056. Users of crates.io are not affected. See blog for more details.

Contributors to 1.94.1

Many people came together to create Rust 1.94.1. We couldn't have done it without all of you. Thanks!

Security advisory for Cargo

2026-03-21T00:00:00+00:00

The Rust Security Response Team was notified of a vulnerability in the third-party crate tar, used by Cargo to extract packages during a build. The vulnerability, tracked as CVE-2026-33056, allows a malicious crate to change the permissions on arbitrary directories on the filesystem when Cargo extracts it during a build.

For users of the public crates.io registry, we deployed a change on March 13th to prevent uploading crates exploiting this vulnerability, and we audited all crates ever published. We can confirm that no crates on crates.io are exploiting this.

For users of alternate registries, please contact the vendor of your registry to verify whether you are affected by this. The Rust team will release Rust 1.94.1 on March 26th, 2026, updating to a patched version of the tar crate (along with other non-security fixes for the Rust toolchain), but that won't protect users of older versions of Cargo using alternate registries.

We'd like to thank Sergei Zimmerman for discovering the underlying tar crate vulnerability and notifying the Rust project ahead of time, and William Woodruff for directly assisting the crates.io team with the mitigations. We'd also like to thank the Rust project members involved in this advisory: Eric Huss for patching Cargo; Tobias Bieniek, Adam Harvey and Walter Pearce for patching crates.io and analyzing existing crates; Emily Albini and Josh Stone for coordinating the response; and Emily Albini for writing this advisory.

What we heard about Rust's challenges

2026-03-20T00:00:00+00:00

Author's note

The original version of this article has been retracted. I used an LLM to write the first draft, though this had come after many hours of planning and going through the data and analyses to identify the points to be made, as well as me going through the post line by line, editing into my voice and verifying the wording and scope of the text was accurate. However, many people still felt like the LLM-speak bled through in ways that felt uncomfortable. Given this, I and other members of the Rust Project have decided to retract the post in its entirety.

I stand by the content of the post. As I said, the LLM did not decide the points to be made - those were done well in advance of even beginning to write the blog post. And, admittedly, I did need to make edits to dampen the scope of them (in large part because I couldn't find specific quotes to substantiate them, even though I often "felt" that they were true given what I know as a Rust Project member), but in general I (and the Vision Doc team) defined the content, not an LLM.

Many people thought that the blog post felt "empty", with no "real substance". While I see the point here, this is unfortunately just how the data played out and goal of this effort. The Vision Doc team conducted ~70 interviews (mostly 1:1), which were the basis for the conclusions in this blog post. This is a lot of data, it's hard to fully capture the essence of them in a single blog post. And yet, it is also not enough data to fully capture the nuance of differences across groups of different types. On top of this, it shouldn't be that unexpected the problems we heard about in these interviews are the same problems that we (and many others) mostly already knew existed. The insight these interviews give us is that they allow us to begin to capture for whom which issues are most prominent.

The insights we identify and the conclusions we make are supported by the data we have gathered. When making these posts, the Vision Doc team has tried to stay as neutral as possible, doing our best to not exert bias by making any claims that cannot be supported as stated by the data itself. With drastically more time, I would have loved to pull in data from the ~5500 survey responses we got, which ultimately could help us make stronger claims or conclusions, but unfortunately that is time that I haven't had. That shouldn't diminish the substance of the insights and conclusions we have been able to make though.

Wording matters though. And it's clear that to many people, the blog post as-written didn't meet the mark that they want. LLMs are a tool that many people use (including me, obviously) to varying degrees to help do things that they couldn't do before (either for lack of skill, lack of time, or lack of motivation). In this case, I used an LLM to compensate for the lack of time for me to dedicate to sifting through transcripts for the ~70 interviews we did, and the many analyses that followed, to find specific quotes and write an early draft. It certainly did not help that writing and editing of this post happened over the span of about 3 months - meaning that things that "worked" in early edits did not necessarily work in later edits.

This all being said, I think that we as a Vision Doc team owe it to the Rust Project and the community to share (at least to some extent) what we have learned here. So, I have taken the original challenges identified by the team (without the recommendations or conclusions) and will provide a brief personal commentary on them. I've chosen to exclude any specific quotes - rather, just focus on the "high level" ideas. So, as a disclaimer, this will mean that the statements here will be much more biased than what we typically want to publish as part of the Vision Doc work.

Across the ~70 interviews the Vision Doc team conducted, we heard a lot of complaints. Of course, we tried to keep these interviews pretty high-level, not focusing on any particular technical details. Rather, we wanted to get a general sense of what the difficulties were that people encountered, among the other topics discussed during these interviews. Here, we've identified a few common challenges to most people, and then a few challenges that are more domain-specific.

Challenges that are universal

We heard a number of things that basically everyone said was an issue for them, in some capacity. Doing things to address these issues could have a universal impact, but that is not to say that these issues necessarily block people from using Rust.

The universal challenges, you've definitely heard before. If you write Rust, you've probably encountered them. That's what makes them universal. However, the point is that we share the data that we gather, and the fact that we have learned that these challenges do affect everyone is data in itself: we have sampled different domains, different experience levels, and different backgrounds; and we have found that these challenges exist for everyone.

Compilation performance

Everybody knows that "compile times" are a thing that Rust is known for. This is an ever-moving target: the Rust Project tracks performance of the compiler on every merged change to track regressions, many people have attempted many times to make substantial progress here, and yet there is always more that we want to or could do.

The good news, is that among our interviews, nobody really told us that compilation time currently blocks them. We did hear things to the effect of "if we keep writing more and more Rust code, we may eventually get to a point that compile times are an issue", so that's not to say that we're "in the clear" but it is important to think about how this matters on balance with other challenges that people face.

Borrow checking and ownership

Again, another thing that Rust is known for. Borrow checking and ownership is a hard topic that basically every beginner struggles with. However, we found that "Rust experts" don't really complain about the borrow checker anymore: it is a challenge that goes away with experience. That's not to say we can't do better for beginners, but it's not clear exactly what that means.

Certainly learning materials and compiler error messages help, and these are areas that we've tried in the past and today to sincerely provide the best experience. Despite that, the borrow checker remains a difficult part of the Rust language. We have ongoing efforts to improve the borrow checker, but it's likely that there are (for example) language features that may make this better. (Or worse!)

We found previously that what makes Rust great is the balance that we put on reliability, efficiency, and versatility. And, we need to be careful when adjusting something as core as the borrow checker to maintain this balance.

Async

When conducting our interviews, async was consistently something that many people had issues with. Beginners often said that they basically completely ignore async while learning. People who do use async often said that the choice wasn't always clear, and that even though using async feels like the right choice now, they still encounter issues.

Fortunately, unlike performance and the borrow checker, we have a number of clear "next steps" for async (e.g. async fns in traits, async drop, async version of std traits) that will begin to solve these issues and close the gap. Of course, for other things (like the coloring problem), we don't have good "solutions" just quite yet.

Ecosystem crates

We previously talked about how crates.io creates a wealth of resources for people to turn to, but people still run into issues. For one, when there are crates that do the thing people want, they need to know: which crates do the things they need, which crates can they trust, and which crates are just overall the "best" for them. Further, in some domains and industries, there aren't crates that do what people need; Rust support for some industries are still too immature.

Challenges that are domain-specific

Though more challenging given the limited diversity in the interviews we conducted, we still were able to find some domain-specific challenges: at least, we were able to hear about some challenges that seem to disproportionately effect some domains over others.

Embedded

For developers programming for embedded systems, we heard most often about the difficulties that fundamentally boil down to constrained resource management. For example, embedded developers are often unable to use the vast majority of the crate ecosystem, they often have trouble using the standard library, and the debugging experience is generally harder. Things that are "normal" for most Rust developers are oftentimes "special" for embedded developers.

Safety-critical

We made an entire post about shipping Rust in safety critical systems. The biggest issue for safety-critical developers with Rust is the lack of availability or maturity for tools to certify their Rust code.

GUI development

The biggest issue heard from GUI developers is compilation time but is slightly different from the general case, because GUI development is so heavily dependent on the visual changes - and so this is a slightly different workflow than just "check if the code compiles and passes tests".

Rust Blog

Project goals update — April 2026 (end of 2025H2)

Table of contents

Flagship: Beyond the &

Plan for 2026

Blockers

Help wanted

Flagship: Flexible, fast(er) compilation

Flagship: Higher-level Rust

Blockers

Blockers

Blockers

Flagship: Unblocking dormant traits

Other goal updates

Blockers

Help wanted

Blockers

Blockers

Help wanted

autodiff

offload

autodiff

offload

#![register_tool] rust#66079

-Zdebuginfo-compression rust#120953

-Zdirect-access-external-data rust#127488

-Zdirect-access-external-data rust#127488

--emit=noreturn

--emit=noreturn

Deref / Receiver

Arbitrary Self Types rust#44874

derive(CoercePointee) rust#123430

Pass pointers to const in assembly rfc#3848

Field Projections goal#390

In-place initialization goal#395

Macros, attributes, derives, etc.

Removing the likely/unlikely hints in favour of cold_path

Niche optimizations

Vendoring zerocopy

New trait solver

2026 Project goals

2026 Project goals

Field projections

rustfmt imports formatting and trailing slashes

Const generics

statx

zerocopy features in Rust's std

Deref/Receiver

null-ptr-deref

In-Place Initialization

Current state

Path towards stabilization

cargo report commands

cargo report sessions

cargo report rebuilds

Log message schema

Log infrastructure

Nested Cargo calls

How contributors can help

Help wanted

Blockers

Rust is participating in Outreachy

What is Outreachy and how is it different than Google Summer of Code

We are mentoring 4 interns for the May 2026 cohort

Calling overloaded C++ functions from Rust

Code coverage of the Rust compiler at scale

Fuzzing the a-mir-formality type system implementation

Improve the security of GitHub Actions of the Rust Project

What's next

Raising the baseline for the `nvptx64-nvidia-cuda` target

Why are the requirements being changed?

What happens when I update to Rust 1.97?

Announcing Google Summer of Code 2026 selected projects

Selected projects

Announcing Rust 1.95.0

What's in 1.95.0 stable

cfg_select!

if-let guards in matches

Stabilized APIs

Destabilized JSON target specs

Flagship: Beyond the `&`

`#![register_tool]` rust#66079

`-Zdebuginfo-compression` rust#120953

`-Zdirect-access-external-data` rust#127488

`--emit=noreturn`

`--emit=noreturn`

`Deref` / `Receiver`

`derive(CoercePointee)` rust#123430

Removing the `likely`/`unlikely` hints in favour of `cold_path`

`statx`

`Deref`/`Receiver`

`cargo report` commands

`cargo report sessions`

`cargo report rebuilds`

`cfg_select!`

What is `--allow-undefined`?

What's wrong with `--allow-undefined`?