Rust Project Goals

The 2025h2 goal period is now over, so I'm closing this issue. Thanks to everyone who contributed! The experimental language specification goal will continue this work in the 2026 period. Authors are welcome to leave a final comment about the goal's outcome.

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

There has been a lot of progress and the regular meetings were as useful as always, thanks a lot everyone!

(and to Tomas for keeping track of things and taking minutes, even when the meetings ran over :)

I hope the next period will be the one that sees the Linux kernel essentially removing the last three unstable language features we use (modulo the new ones being added), and getting very close to finishing the list of the compiler features side too.

The 2025h2 goal period is now over, so I'm closing this issue. Thanks to everyone who contributed! This work continues in the 2026 period via the Rust for Linux roadmap, which includes the Arbitrary Self Types, build-std, Full Const Generics, Const Traits, Field Projections, In-place initialization, Immobile types and guaranteed destructors, and Supertrait auto impl goals. Authors are welcome to leave a final comment about the goal's outcome.

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.

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: https://github.com/rust-lang/libs-team/issues/761#issuecomment-4132354333.

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.

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(https://github.com/rust-lang/rustfmt/issues/3361#issuecomment-3382614679).

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.

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.