Rust Project Goals

In addition to further ongoing work on reference material (some of which is on track to be merged), we've had some extensive discussions about reference processes, maintenance, and stability markers. Niko Matsakis is putting together a summary and proposal for next steps.

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

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.

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: https://rust-lang.github.io/beyond-refs.

Field Projections goal#390

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

Tyler opened a wiki to keep all the proposals, resources in one place: https://rust-lang.github.io/beyond-refs.

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 replacable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion.

Quick bit of great news: Rust in the Linux kernel is no longer treated as an experiment, it's here to stay 🎉

https://lwn.net/SubscriberLink/1050174/63aa7da43214c3ce/

Key developments

• FCP has ended on frontmatter support, just awaiting merge (https://github.com/rust-lang/rust/pull/148051)
• Cargo script has entered FCP (https://github.com/rust-lang/cargo/pull/16569)

Blockers

• Potential issues around edition, see https://github.com/rust-lang/rust/issues/152254

Key developments

• #146377 has been decided and merged

Blockers

• T-lang discussing CR / text direction feedback: https://github.com/rust-lang/rust/pull/148051#issuecomment-3638326490
• T-rustdoc deciding on and implementing how they want frontmatter handled in doctests

Key developments

• A fence length limit was added in response to T-lang feedback (https://github.com/rust-lang/rust/pull/149358)
• Whether to disallow or lint for CR inside of a frontmatter is under discussion (https://github.com/rust-lang/rust/pull/149823)

Blockers

• https://github.com/rust-lang/rust/pull/146377
• rustdoc deciding on and implementing how they want frontmatter handled in doctests