No major updates this cycle - we're still working through feedback on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and prototyping the implementation to be prepared.

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.

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

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.

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

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)

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.

Updates from the 2026-01-28 and 2026-02-11 meetings:

-Zdirect-access-external-data rust#127488

Gary Guo's fix PR was merged: https://github.com/rust-lang/rust/pull/150494

--emit=noreturn

Miguel Ojeda reiterated that this is high on the list of compiler features the project needs. Right now, they're doing these checks manually: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/check.c#n186.

Improving objtool's handling of noreturn is on Gary Guo's radar but there wasn't time yet.

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.

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.

• @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)

Both the MCP and the PR for the AddressSanitizer target have been merged (https://github.com/rust-lang/compiler-team/issues/951, https://github.com/rust-lang/rust/pull/149644). Next up I should prepare the MCP for the Memory- and ThreadSanitizer targets, hopefully sending out soon.

We had a bit less time this month, the update will be shorter, but still meaningful I hope:

• https://github.com/rust-lang/rust/pull/150551 has landed, and it feels stabilizable. To me, this part of the goal is achieved.
• still, "stabilizable" is not stable, and there is more work to do. We plan to stabilize this year, and the project goal proposal for 2026 tracks how.
• Tiif is still deep in https://github.com/rust-lang/rust/pull/152051, and a-mir-formality work with Niko and I.
• Amanda has opened a few cleanup PRs (https://github.com/rust-lang/rust/pull/152438, and https://github.com/rust-lang/rust/pull/152579), and https://github.com/rust-lang/rust/pull/151863 has landed already. She also has started looking into Tage's old PR to see if we can fix it, benchmark it more accurately, and see the cool parts there that we could be using.
• Jack is possibly going to have some time to work with us this year! His help will be very welcome, especially as I will have less time available myself.
• we'll be tracking the opaque type region liveness soundness issue in https://github.com/rust-lang/rust/issues/153215, and I've added a couple tests, in case tiif's PR or anything that impacts them lands.
• some of the tiny cleanups I mentioned last time have also landed in https://github.com/rust-lang/rust/pull/152587.

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

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.

nothing this month, been busy again

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