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/

Update from the 2025-12-03 meeting.

Deref / Receiver

Ding keeps working on the Reference draft. The idea is still not well-proliferated and people are not convinced this is a good way to go. We hope the method-probing section in Reference PR could clear thins up.

We're keeping the supertrait auto-impl experiment as an alternative.

RFC #3851: Supertrait Auto-impl

Ding addressed Predrag's requests on SemVer compatibility. He's also opened an implementation PR: https://github.com/rust-lang/rust/pull/149335. Here's the tracking issue: https://github.com/rust-lang/rust/issues/149556.

derive(CoercePointee)

Ding opened a PR to require additional checks for DispatchFromDyn: https://github.com/rust-lang/rust/pull/149068

In-place initialization

Ding will prepare material for a discussion at the LPC (Linux Plumbers Conference). We're looking to hear feedback on the end-user syntax for it.

The feature is going quite large, Ding will check with Tyler on the whether this might need a series of RFCs.

The various proposals on the table continue being discussed and there are signs (albeit slow) of convergence. The placing function and guaranteed return ones are superseded by outpointer. The more ergonomic ideas can be built on top. The guaranteed value placement one would be valuable in the compiler regardless and we're waiting for Olivier to refine it.

The feeling is that we've now clarified the constraints that the proposals must operate under.

Field projections

Nadri's Custom places proposal is looking good at least for the user-facing bits, but the whole thing is growing into a large undertaking. Benno's been focused on academic work that's getting wrapped up soon. The two will sync afterwards.

Update from the 2025-11-19 meeting.

rustdoc checking for private and hidden items (rust##149105 & rust#149106)

Miguel proposed Rust Doc checking for invalid links to items that are hidden or private even if no docs are built for them. This can help catch typos or dead links because the docs became out of date.

Guillaume was much more open to this being a toggle, lolbinarycat opened a PR here: https://github.com/rust-lang/rust/pull/141299

unsafe_op_in_unsafe_fn not respected in imported declarative macros rust#112504

This lint doesn't trigger when importing a declarative macro that's calling unsafe code without having an unsafe block and without a SAFETY comment.

The lint is only triggered when the macro was actually used.

Fix for imports_granularity is not respected for #[cfg]'d items / rustfmt#6666

Ding opened a PR to fix this: https://github.com/rust-lang/rustfmt/issues/6666

rustfmt trailing comma hack

Ding and Manish were talking about writing up a proper fix for the vertical layout that's currently being solved by the , //, hack

TypeId layout

This has been discussed in https://github.com/rust-lang/rust/pull/148265 and https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/TypeID.20design/near/560189854.

Apiraino proposed a compiler design meeting here: https://github.com/rust-lang/compiler-team/issues/941. That meeting has not been scheduled yet, though.

Deref / Receiver

Following TC's recommendation, Ding is drafting the Reference PR.

Arbitrary Self Types and derive(CoercePointee)

Ding opened a PR to fix unsoundness in the DispatchFromDyn trait: https://github.com/rust-lang/rust/pull/149068

Theemathas opened a question on whether Receiver should by dyn-compatible: https://github.com/rust-lang/rust/issues/149094

RFC #3848: Pass pointers to const in assembly

Merged!

In-place initialization

Benno noted that Effects and In-place Init are not compatible with each other: https://rust-lang.zulipchat.com/#narrow/channel/528918-t-lang.2Fin-place-init/topic/Fundamental.20Issue.20of.20Effects.20and.20In-place-init/with/558268061

This is going to affect any in-place init proposal.

Benno proposes fixing this with keyword generics. This is a topic that will receive a lot of discussion doing forward.

Alice has been nominated and accepted as language-advisor. Fantastic news and congratulations!

Update from the 2025-11-05 meeting.

Deref/Receiver

Ding Xiang Fei posted his reasoning for the trait split in the Zulip thread and suggested adding a second RFC to explain.

TC recommended writing a Reference PR. The style forces one to explain the model clearly which should then make writing the RFC easier.

The lang experiment PR for arbitrary self types have feature gates for the two options we're exploring.

Arbitrary Self Types and derive(CoercePointee) / tracking issue #44874

theemathas opened an issue derive(CoercePointee) accepts ?Sized + Sized #148399. This isn't a critical issue, just an error that arguably should be a lint.

Boxy opened a fix for a derive(CoercePointee) blocker: Forbid freely casting lifetime bounds of dyn-types .

RFC #3851: Supertrait Auto-impl

Ding Xiang Fei is working on the implementation (the parser and HIR interface for it). Ding's also working on a more complete section dedicated to questions raised by obi1kenobi

Field projections

Benno Lossin has been posting super detailed updates on the tracking issue

We've discussed the idea of virtual places (see Zulip thread where they were proposed).

Inlining C code into Rust code

Matt Mauer had an idea to compile C code into LLVM bytecode (instead of object file) and then the llvm-link tool to merge them together and treat everything in the second bytecode file as a static inlined function. Matt suggested we could integrate this into the rustc passes.

This would make it easy to inline certain functions into Rust code without full LTO.

Relevant Zulip thread.

This sounds like a good candidate for the next Project Goals period.

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

Key developments

• rust-lang/rust#148051

Blockers:

• rustdoc deciding on and implementing how they want frontmatter handled in doctests