Rust Project Goals

Update this cycle is the same as last time - rust-lang/rfcs#3874 and rust-lang/rfcs#3875 are progressing, with feedback being addressed and checkboxes checked, and we're still working out what the implementation would look like.

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.

• 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`

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.

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.

Update from the 2026-03-11 meeting:

--emit=noreturn

It seems that figuring out which functions are noreturn is at a level too low for rustc. Function signatures are not sufficient and there are cases where rustc doesn't know whether to emit noreturn. It is something we should ask the LLVM to give us that information.

-Zsanitizer=kernel-hwaddress

Alice Ryhl opened a new issue to introduce the -Zsanitizer=kernel-hwaddress sanitizer for aarch64 targets: https://github.com/rust-lang/compiler-team/issues/975

-Zharden-sls

Wesley Wiser is working on https://github.com/rust-lang/rust/pull/152821 which the -Zharden-sls patch should be rebased on top.

#![register_tool]

The corresponding RFC has been discussed by the Lang team on 2026-03-11. The overall vibe was positive and TC is going to read through it and hopefully check a box on the proposed FCP.

-Zdebuginfo-compression

The proposed stabilization received some feedback that needs to be addressed.

-Zdirect-access-external-data

The discussion here has stalled.

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.

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

• 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

Status update March 9, 2026

After the initial PR from the last update was merged, we shifted our focus to resolving some of the known issues. Notably, locking blocks the Cargo job queue slowly causing thread starvation if many build units are held by another Cargo instance.

We investigated adding the ability for Cargo to "suspend" a job internally while waiting for a lock, but we felt this change was a bit invasive and did not fit well with how the job queue was designed. Instead we plan to change our design to acquire all build unit locks prior to running the job queue. (see https://github.com/rust-lang/cargo/pull/16657)

At the same time, we have continued to refine the new build-dir to prepare it for a call for testing and eventual stabilization. (https://github.com/rust-lang/cargo/pull/16542, https://github.com/rust-lang/cargo/pull/16502, https://github.com/rust-lang/cargo/pull/16515, https://github.com/rust-lang/cargo/pull/16514)

Finally we decided to split .cargo-lock into 2 locks to allow cargo check and cargo build to run in parallel when artifact-dir == build-dir (and -Zfine-grain-locking is enabled)

I suspect this may be the last update on this goal, as the 2026 slate of goals is coming up. While I did not renew this goal for 2026, I do plan to continue work on this and eventually stabilize this within this year.

The targets for MSan and TSan are merged now: https://github.com/rust-lang/rust/pull/152757.

Next, I'll be working on stabilizing those two, now that we have a way to use it without other unstable features (build-std).

Key developments

• Cargo's FCP has ended

Blockers

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

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.

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

busy...