Rust Project Goals

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

cc Hristian Kirtchev, Tshepang Mbambo, TC , Alex Eris Celeste née Gilding for any updates I missed to share them

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.

This work is now continuing into a new goal by Jack Huey; see https://github.com/rust-lang/rust-project-goals/pull/490 .

Key developments:

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!

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 here: https://github.com/rust-lang/rfcs/pull/3633.

Deref/Receiver

Jack Huey started reviewing Ding Xiang Fei's rust#146095 split the autoderef chain PR 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: https://github.com/rust-lang/all-hands-2026/issues/17.

Here's a meta issue tracking all the proposals and discussions about the feature: https://github.com/rust-lang/rust/issues/153825.

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