Key developments: What has happened since the last time.

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

Blockers: List any Rust teams you are waiting on and what you are waiting for.

Nothing at the moment, everyone has been extremely helpful, and I'm getting good feedback on use cases, problems, priorities, and Rust language experiments.

Help wanted: Are there places where you are looking for contribution or feedback from the broader community?

Suggestions for more interop use cases or problems 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 or problem ticket directly.

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.

I'll post an update here every few weeks, you can follow more detailed weekly updates on Zulip.

Hi, I'm the new contractor on the interop problem space mapping project goal.

Key developments: What has happened since the last time. It's perfectly ok to list "nothing" if that's the truth, we know people get busy.

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

Blockers: List any Rust teams you are waiting on and what you are waiting for.

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

Help wanted: Are there places where you are looking for contribution or feedback from the broader community?

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.

Next step is prioritising a few of the use cases, then working on related problem statements in more detail.

I'll post an update here every few weeks, you can follow more detailed weekly updates on Zulip.

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.

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.

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

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.

Latest updates:

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: https://rust-lang.github.io/rust-project-goals/2026/const-generics.html

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 @ 💬

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

#![allow(unused)]
fn main() {
#[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!

• Key developments:
  • https://github.com/rust-lang/rust/pull/149130, coercion support of &pin T types, merged.
  • https://github.com/rust-lang/rust/pull/153693, borrow check of &pin place borrows, draft PR opened. The implementation needs to be refined and self-reviewed before the community reviews.
• Help wanted:
  • https://github.com/rust-lang/rust/pull/144537. I failed to reproduce the CI errors locally. Hopefully, someone can help explain where (in which file) the links break

reference/print.html:42240: broken link fragment `#tymethod.drop` pointing to `core/ops/drop/trait.Drop.html`
reference/destructors.html:201: broken link fragment `#tymethod.drop` pointing to `core/ops/drop/trait.Drop.html`

(Just come back from the Spring Festival)

• In development:
  • (locally, no PR yet): design and implement the borrow checking algorithms of &pin
  • https://github.com/rust-lang/rust/pull/144537, reviewed, to update the submodule book
  • https://github.com/rust-lang/rust/pull/149130, reviewed, to do some refactors according to the reviewed messages.

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. You can find the design document as well as the meeting minutes here: https://hackmd.io/H5d2-83ER2ymNPZVIWCYWg.

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:

• Can we support reads/writes of different types?
• Can we support re-assembly of wrapper types, so going from Cell<[T]> to [Cell<T>]?
• The PlaceDiscriminant trait needs to be carefully designed
• How do we handle naming conflicts & ensure SemVer evolution of library types implementing our traits?
• Can we support projecting through Option, so e.g. &Option<Struct> to Option<&Field>?
• Can we support a pointer that carries alignment information & which is updated on projections?
• What compatibility with effects do we need or want to support?
• What doors on future ergonomic improvements of pointers are we closing by having field projections?

Thanks to everyone who participated in the meeting!

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 https://github.com/rust-lang/rust/issues/145383. 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.

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:

#![allow(unused)]
fn main() {
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):

#![allow(unused)]
fn main() {
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)

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.

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

Key developments: 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. Blockers: None currently 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.

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.

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.

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.

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!

Key developments:

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. In https://github.com/rust-lang/rust/pull/150683 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 bootstraping logic, and as part of that start building offload in CI.

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.

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.

A proposal to continue this goal in the next goal period was merged: https://github.com/rust-lang/rust-project-goals/pull/477

The RFC has just been published as https://github.com/rust-lang/rfcs/pull/3943. 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.

Key developments

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:

#![allow(unused)]
fn main() {
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:

#![allow(unused)]
fn main() {
#[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.

• I added support for getting reflection information of any type, not just 'static ones
  • https://github.com/rust-lang/rust/pull/152381
• @9SonSteroids added a function pointer MVP and trait object support
  • https://github.com/rust-lang/rust/pull/152173
  • https://github.com/rust-lang/rust/pull/152003
• Asuna added basic struct/enum/union support
  • https://github.com/rust-lang/rust/pull/151142

• @BD103 added slices, arrays and raw pointer support
  • https://github.com/rust-lang/rust/pull/151019
  • https://github.com/rust-lang/rust/pull/151031
  • https://github.com/rust-lang/rust/pull/151118
  • https://github.com/rust-lang/rust/pull/151119
• Asuna added all of our primitives
  • https://github.com/rust-lang/rust/pull/151123
• Jamie Hill-Daniel gave us references
  • https://github.com/rust-lang/rust/pull/151222
• @izagawd made it possible to extract some info from dyn Trait
  • https://github.com/rust-lang/rust/pull/151239

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)

• https://github.com/rust-lang/rust/pull/146923 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.
• https://github.com/rust-lang/rust/pull/150033 has landed, and I'm working on removing the 'static requirement in https://github.com/rust-lang/rust/pull/150161

Key developments

• Cargo's FCP has ended

Blockers

• https://github.com/rust-lang/rust/issues/152254

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

Per last comment, rust-lang/rfcs#3729 has been updated

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.

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.

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

RFC has been accepted. I'm preparing a 2026 continuing goal for stabilization.