Posts tagged "program" | Rust Blog

Leadership Council update — September 2026

2026-09-28T00:00:00+00:00

Hello again from the Rust Leadership Council! We wanted to share an update on what the Council has been working on since our last update.

Accomplishments so far

Welcome Mark Rousskov and Pete LeVasseur to the Council

Every six months, the Leadership Council performs a Council representative election, to elect new representatives of several top-level teams. This time, the representatives of the Infrastructure, Language, Library, and Moderation teams were elected.

The September representative selections have completed. Here are the results:

Jakub Beránek (@kobzol) will continue representing the Infrastructure team
Pete LeVasseur (@PLeVassuer) will represent the Language team
Mark Rousskov (@Mark-Simulacrum) will represent the Library team
Oli Scherer (@oli-obk) will continue representing the Moderation team

We welcome Pete and Mark to the Leadership Council!

We would also like to thank our outgoing representatives TC and Josh Triplett for their time on the Council. We appreciate your help and support!

Thanks to everyone who participated in the process! The next representative selections will be in March 2027 for the other half of the Council.

Project Director Elections

Same as last year, the Leadership Council has launched an election to select two new Project Directors who will sit on the Rust Foundation Board of Directors (#324). The nominations for the Director positions have been gathered, but the actual election will happen in October. Once we know the two elected Project Directors, we will announce them on the Rust Blog.

Rust Foundation Maintainers Fund

Since the last update, we decided to allocate an additional $120k to the recently established Funding team (#328), in addition to the $50k which we have already allocated previously.

The funding team used this money, together with other funds from the Rust Foundation Maintainers Fund to financially support seven Rust contributors, five Maintainers in Residence and two Maintenance Grantees. Read the announcement blog posts (1, 2) to learn more.

Project priorities budget

Since 2024, the Project has managed a Project Priorities budget. The council spends funds from this budget on activities that support the work of the Project.

At the start of July, we led talks about the Project Priorities budget with Rust Project Directors and the Rust Foundation. Based on those discussions, we decided to spend the whole available budget every year, instead of keeping a buffer for the following year, which is what we have been doing so far (#314). This makes tracking of the budget and accounting simpler, and it also has the benefit of giving us more money to spend in 2026! You can find the additional allocations that we made since the last update below.

As mentioned above, $120k was allocated to the Funding team for further spending on maintainer support (#318).
An additional $32k was allocated to the Mentors team for the next Outreachy round in December 2026 (#320).
We allocated an additional $32,325 to the travel budget for Rust Project members, in addition to the $100k that we previously allocated for 2026 (#316).

LLM policy discussions

The Council, together with many other members of the Rust Project, spent a lot of time discussing various policies related to using Large Language Models (LLMs) when interacting with the Rust Project and its repositories. Thanks to the awesome work of jyn514 and many other people, the main rust-lang/rust repository now has an official LLM policy. Several other rust-lang/rust repositories followed suit and adopted this policy, usually with slight modifications.

That is not the end of the policy discussions though, because we would also like to have a Project-wide policy, and also have someone who will be responsible for updating the policies in the future. After many discussions, we settled on creating a new LLM policy team, to which we delegated the responsibility of coming up with a Project-wide policy and updating our existing LLM policies.

Additional items

We updated the Council observer policy, which specifies who can join the Council meetings and what they are allowed to do during them. The updated policy reflects more accurately how our meetings work today, and is generally more permissive (#110).
We slightly updated the suggestions for the Leadership Council representative selection process. The guidelines now suggest consulting Council candidates with the moderator team prior to them being selected as Council members (#327).
Tomáš Šedovič, one of the members of the Program Management team who was previously funded from our Project Priorities budget, has now been hired as a full-time employee by the Rust Foundation! We are very happy about that.
We finished the annual Council survey to receive feedback from Project members on the Council (surveys#409). We are analyzing the results now, and will share them with Project members once the analysis is complete.

A word of thanks

For the past couple of years, the Leadership Council update blog posts were always prepared and written by Eric Huss, who has recently left the Rust Leadership Council. We wanted to thank him for all the work he put into them, and all his contributions to Rust. Thank you very much, Eric!

Following our work

As you can see from the many links above, the work of the Council happens mostly in public on GitHub issues posted in our repository. The items on our meeting agendas are drawn from these. After discussing an item, we summarize that discussion and any shared rationales on the issue. When we make decisions, we propose on the issue a "final comment period" (FCP), and as with all FCPs in the Project, we're interested in and review any feedback that people have before or during this final comment period.

To follow our work in real time, watch our repository. You can also see meeting summaries posted on Zulip in #council > Meeting minutes & summaries.

Meeting minutes

We publish minutes from all Council meetings to the Leadership Council repo. Links to the minutes since our last update are:

July 3, 2026
July 17, 2026
July 31, 2026
August 14, 2026
August 28, 2026
September 11, 2026: cancelled due to RustConf

Program management in July–August 2026

2026-08-31T00:00:00+00:00

It's been fun since the last update. Tomáš was away for a month, and I had to get my wisdom teeth pulled right after he left.

Despite everything, a lot has happened!

Project Goals

Since the previous update, we've opened seven more goals:

Contracts: primitive ownership assertions
Process-Safe Rustup Toolchain Operations
End-to-End Executable Rust Specification
f16b Primitive Type
Polymorphic code generation experiment
C interop: Complex<T>
Allocators 1.0

There's now a roadmap for Binary size reduction, which includes async future and statemachine optimization goals, build-std, and future possibilities that aren't goals yet.

One goal was completed (Stabilize Cargo's linting system), and two were discontinued (Experimental language specification and Continue Experimentation with Pin Ergonomics).

Several goals have received partial funding (Incremental Systems Rethought, Native async fn dynamic dispatch in traits, and Cargo cross workspace cache), and some are now fully funded (C interop: f80, f128, and c_longdouble, C interop: Complex<T>, and Async statemachine optimization). Don't forget to add your goal to the funding table if it needs funding (see template)!

Some goal owners and contributors have been writing about their work beyond the regular goal updates. Here are some of the places to check out:

Monthly updates by Hexcat
Rust Maintainer Monthly Report: August 2026 by Gen Li
Status Update - July 2026 by the BorrowSanitizer team
Field Projection Designs by Benno Lossin
Four levels of in-place initialization by Yoshua Wuyts
Optimizing the new trait solver by Jana Dönszelmann
Rust Function Overloading - Call for Experimentation by teor
A Vision for a Rust Formal Specification by Nadrieril

Infrastructure

The Goals repository has been renamed to rust-lang/goals from the verbose rust-lang/rust-project-goals, and we've renamed the Zulip channels to #goals, #goals/proposed, and #goals/meta. The website now lives at goals.rust-lang.org; the old links should redirect there.

Triagebot used to ping every #goals topic twice a month, which was incredibly noisy to anyone following that channel. Many of the goal owners weren't even subscribed to it, so they never received the reminders. This was finally reworked, and now goal owners receive one private message with an aggregate of all their goals needing updates. Some wanted triagebot to ping them more often, and it's now possible to configure the reporting frequency per goal (weekly, biweekly, or the default of every four weeks). Let us know how you like it!

We've set up the automatic creation of Zulip topics for labeled goal proposals in #goals/proposed so that there's less friction in soliciting team champions and collecting feedback.

Team building

The Goals team now has a regular meeting every Thursday at 14:00 UTC. We use that time to figure out what the program should mean, how it should be implemented, and how we can communicate it better to the audiences involved.

If you have any wishes, complaints, or thoughts about the Goals program, you can join the meetings or reach out to us!

Content

Seems like we've accidentally created a rite of passage in which a program manager has to anxiously get involved in at least one t-content production :-). I've mentioned before that I got to interview Alice Cecile (Bevy Engine) at RustWeek. This and twelve other interviews are now available on YouTube, so feel free to check them out!

The content team has started publishing interviews from RustConf and Kangrejos 2025 as well.

Apart from that, the team has been producing a series about Rust release changelogs. Here's the 1.97 episode! They're hoping to involve more people from across the Project in future episodes (and other videos), so that maintainers and contributors can talk about their work directly. Be on the lookout for a call for participation if you're interested or know someone who might!

Fun fact: I actually met Chris Biscardi at RustWeek and invited him to a content team meeting about the changelog series. One thing led to another, and Chris ended up joining the team and has been bringing in a lot of valuable content-making experience since! This makes me happy.

Rust for Linux

This cycle, Rust for Linux brought up some more interesting feature requests.

The core of `core`?

One of the topics Rust for Linux has been tracking is modularization of core. This is the ability to remove parts of the core standard library that the kernel doesn't need because of semantic differences or duplication. This includes standard atomics, IO, 128-bit numbers, floating-point numbers, and Unicode tables.

There are different ways to support such modularization, each with its own caveats. Perhaps the most fundamental one is keeping every feature under its own flag, but that requires building the standard library (see the build-std goal) and introduces a combinatorial explosion that's difficult to test. The standard library could also expose a small number of "feature layers" instead, but then it becomes hard to find a partitioning that makes sense for everyone.

Another approach is to define the smallest possible subset of core that's needed for the language to work. This subset, tentatively named lang, would only include things like lang items and could lead to a stable alternative to the internal #![no_core] feature. For now, that seems most realistic, and the RfL team is willing to experiment with it and possibly develop a proposal. Can we get a Project Goal out of this?

Integer casts

There's an ongoing appetite for more intentional casting mechanisms between integers. The kernel already lints against lossless casts, and recently introduced a num::casts module for lossless conversions that are missing from the core library (e.g., u32 -> usize and usize -> u64). This leaves the non-trivial as casts that may truncate or change signedness.

One option would be to lint against cast_possible_truncation, cast_sign_loss, and cast_possible_wrap, and justify each warning with an explicit #[expect(..., reason = "...")]. This gets awkward in kernel code, though, because lint expectations may depend on configuration (see coding guidelines). Miguel has also mentioned that the reason syntax is somewhat verbose, hence the existing request for tooling support for tagged comments like // CAST: ....

We may also get a resolution to this from the API side: the libs team is actively discussing numeric casting APIs, which may address this. See this meta-ACP.

Newtype literal constructors

We also discussed improving the ergonomics of NonZero and other newtypes. Specifically, it would be nice to be able to construct such types from bare literals:

const NONZERO_OK: NonZeroU8 = 42; // works
const NONZERO_BAD: NonZeroU8 = 0; // error

There have been proposals to generalize this to user types, e.g., through a FromLiteral trait family, but nothing that's usable today. So far, the kernel developers have been working around this (and the lack of const traits) using macro hacks.

Project updates

Here are some of the recent Project updates you might have missed:

All Hands 2026 retrospective
Funding team progress update — July 2026
rust-lang/rust is adopting an LLM policy
Leadership Council September 2026 Representative Selections
Announcing our first Maintainers in Residence
Electing new Project Directors 2026

Until next time! <3

All Hands 2026 retrospective

2026-07-31T00:00:00+00:00

In May 2026, 166 Rustaceans gathered in Utrecht for the Rust All Hands. This event is an opportunity for the Rust Project members and invited guests to work on Rust in person for several days — discuss its future, resolve blockers, build connections between teams, and so on (but not make any final decisions!).

This was the second All Hands organized by RustNL, after the one last year revived the tradition after a six-year hiatus. It was part of RustWeek both times, with the Rust All Hands following directly after the conference days. And yes, the All Hands will happen again in 2027! More details on that at the end.

Also co-located with the All Hands was the RustWeek Unconference, where invited ecosystem maintainers and contributors collaborated with each other and with Rust Project members. This year, there were six participating groups: Bevy Engine, Ariel OS, Linebender, the Safety-Critical Rust Consortium, Rust GPU, and Rust Embedded — with around 60 members in total.

Similarly to last year, the conference day right before the All Hands had a special track, the "Rust Project Track", with talks presented by Project members. (See the recordings.). The talks touched on some of the topics that the Rust teams discussed in greater depth in the All Hands sessions.

Sessions

At the All Hands, there were 73 sessions spread across 3 days and 11 rooms, most of which were pre-scheduled, though some happened spontaneously. You can find the session notes in rust-lang/all-hands-2026.

The State of the Rust teams session kicked off the All Hands and provided a (literal) platform for teams to tell everyone about their activities.

Many sessions focused on pressing topics in the Project's governance. The Leadership Council and Project Directors both held Q&A panels about their roles and processes, and how they relate to one another and the Rust Foundation. The moderation panel provided a safe space for Rust moderators to discuss the challenges they face, with support from Q (head moderator of Hachyderm)^[1]. The Project culture discussion examined sources of disempowerment for maintainers and contributors, and ways to address them. The sessions on Project Goals, north stars, and funding looked at improving how the Project coordinates and communicates work^[2]. Finally, there was a discussion about improving the RFC process, possibly by integrating some ideas from the TC39 process.

As expected, most of the sessions focused on the evolution of Rust itself. The teams discussed a wide variety of efforts, including const generics, const traits, field projections^[3] and reborrowing^[4] (1, 2, 3), in-place initialization, SIMD, allocators^[5], custom lints, stability attributes for libraries, rustc as a library^[6], the Sized Hierarchy, and auto traits. Beyond these, there were numerous sessions on compiler internals, codegen, semantics, specification, tooling, and infrastructure.

Interoperability was another prominent topic. Discussions covered the overall Rust/C++ interop problem and solution space^[7], the state of Rust/C++ interop using Crubit^[8], and safer interop via combining LLVM IR with Rust MIR. It was also great to see in-person collaboration between the Rust Project and both Rust for Linux^[9] and Rust for CPython, aimed at unblocking further integration of Rust into the Linux kernel and CPython.

Feedback

Overall, people loved the All Hands! Responders rated it 9.5/10 on average, and indicated they'd return next year if given the chance.

Here are some of the things they shared:

Got some very awesome conversations about effects with Jana Dönszelmann and later Tyler Mandry and Benno Lossin which have gotten me very excited and I'm writing blog posts as we speak.

I'm also full of ideas from the mods convo with Q, that I expect to bear fruit in subtle ways.

We may also have unblocked rustc_public, and are working with t-infra to be able to statically compile a rustc driver.

— Nadrieril

The week was full of good surprises! I was surprised at the significant interest in the things I'm working on, based on conversations and the attendance at the workshops (and the related talks).

I was happy to see we're covering most of the high priority interop issues people are concerned about. That was a really good outcome.

There are also a bunch of exciting things in the early stages of discussions or scoping work. Some might never happen, but if/when they are ready, I'm looking forward to sharing them.

— teor

For cargo-semver-checks, we decided on a path forward for building rustdoc JSON with correct features enabled, which is sufficient to unblock cross-crate analysis. We also agreed that it would be desirable to run it on PRs to the standard library, because accidental breakage happens there too and it's extremely painful to deal with. We have a clear path forward here too.

We also got to consensus that it would be good to ship (on stable) a rustup component with the rustdoc JSON of that target triple's standard library, while making the component itself unstable because the JSON format is not stable. This is a fine line, and we technically only just nailed down the details earlier this week, but the bulk of the spicy conversations happened in person.

I have more, these are just the first things that came to mind. I have probably a year and a half's worth of stuff to build off of just things that got unblocked at RustWeek. Now I just need more hours in the day to code! :)

— Predrag Gruevski

In addition to all the value the Rust Project got out of the "official" portions like the talks, All Hands sessions, etc. I also wanted to give one example of "I randomly bumped into someone in the hallway / at the hotel, and learned something invaluable as a result." It was a stroke of good fortune that I happened to bump into the right people, in the right context, to learn about that obscure edge case that will make cargo-semver-checks a more useful tool for the Rust community. This was far from the only such case at the All Hands!

There's inherent value in having people in the same place, and in facilitating opportunities for informal mingling — whether it's in hallways, at the post-event social sessions, at the hotel(s) where many people are staying, etc. I'm thrilled that the organizing team again paid a lot of attention to creating such opportunities in many ways: with the choice of venue, with how the schedule was created, with offering recommended hotel blocks that were relatively close to each other, etc.

— Predrag Gruevski

I covered so many different and varied topics, from meta-dictionary trait solving with lcnr & the rest of t-types over formality discussions with tiif, Xiang & Nico to talking with Aapo about reborrowing and so many more! (Not to mention the huge amount of people I talked with about field projections!) I feel bad making a list, because inevitably I would forget people, because it was so packed!

— Benno Lossin

my highlight on the technical side is definitely that we seem to have finished the non-aliasing-model parts of the opsem. :) specifically, reference and union validity. FCPs are in progress.

We didnt make as much progress on terminology as I had hoped, though we did uncover new interesting questions which is at least some progress.

— Ralf Jung

I'm thrilled that we settled union operational semantics at the All Hands.

I really appreciated the random conversations with people I didn't know. I'm glad that the event provides a low-friction way for Rust team members to make themselves available to others. :heart:

Oh, another one! I loved the "state of the teams" session (thanks to Lori Lorusso for coordinating it). I know it kinda ballooned with the addition of more teams, and I'm glad it did; I loved having a quick overview of the state of many different teams, including teams I haven't had much view into before.

— Josh Triplett

As someone totally new to the Project getting to meet people in person was really good and totally overwhelming but in a good way. I really enjoyed getting to have discussions with so many different people about a variety of rust and non rust topics. I really appreciate and can't thank the team reps enough that not only supported my session but created it (no way it would have worked if you all didn't step up to the stage) and for Mara giving me the opportunity to thank everyone in the closing session. This event and Mara's support did a lot for me and for what my position hopes to achieve.

— Lori Lorusso

Myself being fairly new, I went in not expecting much beyond just wanting to meet everyone, have a good time and watch people do their thing. But I contributed a fair amount to some meetings and had some very nice and productive 1:1 chats. It's also a totally different feeling contributing to rust now when you've met so many people IRL. 100% would do again.

— mejrs

I was at the unconf rather than the all-hands, but I just wanted to say it was a fantastic experience! Having the two events co-located was great for the ability to build connections between ecosystem and project people and work on problems and solutions together. Everyone I interacted with from the project was incredibly friendly and enthusiastic and projected an infectious can-do attitude about making Rust better. As this was my first-time at a Rust event, I came in feeling a bit intimidated about being in the same building as all these brilliant people who have done such impactful work, and I left feeling welcomed, included, and excited for next year.

— Jonathan Keller

All Hands 2027

The Rust All Hands will return next year! It will be part of RustWeek 2027 in Utrecht, the Netherlands, on 27–29 May.

Save the date, and we'll be sharing more information later!

Huge thanks to Mara and RustNL for keeping up this amazing tradition with such a deep level of care.

See you next year!

See related talk by Antonio Piraino and Oli Scherer. ↩
See related talk by Niko Matsakis and Jack Huey. ↩
See related talk by Benno Lossin and Nadrieril. ↩
See related talk by Aapo Alasuutari. ↩
This renewed the momentum to stabilize Allocator! ↩
See related talk by Alona Enraght-Moony. ↩
See related talk by Teor and talk by Tyler Mandry. ↩
See related talk by Bastian Kersting. ↩
See related talk by Greg Kroah-Hartman and live podcast by Greg K-H and Alice Ryhl ↩

Program management update — June 2026

2026-07-14T00:00:00+00:00

Meetings

We started attending the Types meetings. The topic is something neither of us are deeply familiar with, but the team was extremely welcoming, and kept stressing that we ask questions any time we can't follow something. To help us better understand recent topics, they pointed us to the Well-formedness article on the Rust Compiler Development Guide page.

The Rustdoc team considered having virtual face-to-face meetings in place of the async ones they've been having over Zulip. We joined, and minuted the meeting, but the team decided to stick with async for now. They did raise an interest in doing something akin to the Language Design meetings — and they would appreciate a PM presence there.

Finally, the Types team started a library trait evolution experiment to explore designs for evolving the standard library types (e.g. supertrait auto-impl, Sized hierarchy, and immobile types). There is a Zulip channel for discussion, and a recurring meeting we set up.

Project goals

Funding

Each goal can now add a section requesting funding (e.g., improve rustc_codegen_cranelift performance). Roadmaps now list the funding information across all their goals (e.g., Fast Builds). There is also a funding overview across all goals.

If you have a Project goal that needs financial support, add a funding section according to the template. If you're interested in supporting a goal financially, you may reach out to the contact listed on the funding page.

Help wanted

We also have a page for goals that are looking for contributors, analogous to the funding page. If you're interested in joining an effort, please check it out, and contact the goal owner.

If your goal needs help, add a Help wanted section using the template.

New goals

We've accepted several new goal proposals:

Reintroduce a FCW to borrowck
Allow turbofishing late bound vars
C interop: f80, f128 and c_longdouble
Library Trait Evolution Experiment
View types experiment

We're considering new Project goal proposals year-round! Here's how to propose a new goal. Once you open the pull request, we'll work with you to make sure everything is set.

Note that we still require that the teams with asks on them sign off, and that teams with medium or larger asks have a champion. This is a way to make sure the teams aren't over-committing their capacity.

We're also looking for ways to streamline the current process, let teams handle their goals more directly, and make larger long-term improvements.

Leadership Council

We'd like to highlight a few developments that recently came out of the Leadership Council meetings.

As a reminder: the meetings happen every two weeks on Friday at 11:30 New York time. We publish meeting notes in the Council repo and summaries on Zulip. The draft agenda is usually posted on the Monday before the meeting.

Keep in mind that the Council meetings may be observed by all Project members — if you'd like to join, talk to your representative.

If you don't know who your representative is, look your name up in the All Rust team members page, then click on the teams you're active in, which should get you to the top-level teams (e.g. Compiler, Language, Library, Launching pad, Infrastructure, etc.), and then look up the current representative on the Leadership Council team page.

T-comprehensibility

David Wood proposed chartering a Comprehensibility team:

Comprehensibility is a long-standing deficiency of the Rust Project. New contributors and organisations interested in participating in the project have a difficult time understanding how to contribute, and cross-team collaboration is impeded by mismatched expectations and working practices. Teams retain the ultimate decision making power about the content of their charters, process and policies, but t-comprehensibility will be involved in the drafting and updating to ensure that the project's documentation is consistent and coherent overall.

Documentation (especially process documentation) is something that must be actively maintained, and without a sustained effort it's among the first things to become stale. Having a team of individuals with an interest to keep it updated sounds like a great idea.

The proposal has finished its final comment period (FCP) and is expected to merge. The team creation will follow.

The next All Hands

Mara Bos proposed, and the Council accepted, to hold the next All Hands in 2027, and collocate it with RustWeek, organized by RustNL, once again. They have also agreed to reserve $50,000 for the All Hands out of the next year's Council budget, if there is money left after PMs are paid. This will be in addition to funding the travel grants (again, contingent on the availability of funds).

Based on the feedback received from the All Hands attendees, this is fantastic news for a huge number of people.

LLM committee

oli proposed creating an LLM committee that would have the power (delegated by the Council) to write and edit the LLM policy for the Project. It would be composed of 4-5 people representing the diverse views on the topic across the Project, be trusted by the Council and the Project, and have the ability to work together and make progress despite disagreement.

The team is explicitly designed such that everyone should feel comfortable reaching out to at least one committee member. It should also be able to adapt to the frequent changes in the AI industry without causing too much churn.

This is very much under open, active discussion. It will need a careful read and consideration. We're happy with this development and hope it works out.

On a personal note, I (Tomáš) would love to see Rust moving towards having a clearer policy on the matter, and as a project, we have not done so thus far. I'm curious to see what happens here. I hope we all manage to stay on topic on the issue (this is about how we move forward, not what the policy should be and why).

Program management

There were two proposals concerning Program management opened in the last couple of weeks:

Discuss long-term place for Program Management program by TC
Charter Program Management Team by Rémy Rakic (lqd)

The first one focuses on who's responsible for the funding and management of the Program managers (presently Nurzhan and Tomáš, and possibly Antonio Piraino serving as compiler-ops). Josh Triplett suggests this be the same team that would manage the Maintainers in Residence.

The second one is concerned with chartering the PM team, listing their responsibilities and expectations. People management is work that plenty of people (e.g. TC, Niko Matsakis, Eric Huss) have done before we joined, and it will keep happening. The proposal acknowledges this and formalizes the role.

Rust for Linux

Our regular meetings resumed after the All Hands.

Miguel Ojeda mentioned that zerocopy is now the first (third-party) crate they vendor that can directly generate code in the kernel image \o/.

The team would also like to have a runtime toggle in Rustdoc that would let them show private and hidden items in the documentation. Rustdoc can show this information already, but only at build-time using the --document-private-items and --document-hidden-items. We've opened a discussion on Zulip, but it hasn't been resolved yet.

Finally, Benno Lossin shared an example of what field access would desugar to using the Field projection mechanism of places and handles. This is important because it lets us validate it on existing field projections (e.g. for shared and mutable references), and see exactly what any proposed syntax for extending this to other kinds of pointers would do in normal Rust code that we ship today.

Rust for CPython

Following the discussion at the All Hands, the CPython folks met with us on 2026-07-02 to discuss Project goals.

We came up with some goals worth considering:

Rust in CPython in general (it might make sense for this to be a Roadmap)
Project build design space (building things without using Cargo)
Thread state memory
Stabilizing macro metavar
Stabilizing the Rust dylib format

In some cases, people are either currently working on or have looked into similar areas in the past, so the team will have those conversations first and then start opening goals.

Worth a look

June (and the early bits of July) was extremely prolific in terms of blog posts and announcements!

Project updates

How Josh helps Rust manage code across multiple repositories
April & May 2026 Project Director Update
Rustup update: our plans for the 1.30 release cycle
Leadership Council update — June 2026
Together for a healthier Clippy
Maintainer spotlight: Gen Li (@rami3l)
The many journeys of learning Rust
Announcing Rust 1.96.1
Announcing Rust 1.97.0

Foundation posts

An AI Security Engineer in Residence for the Rust Ecosystem
- Congratulations, Jacob!
Building the Rust Commercial Network: A Home for Rust in Production
Rust Foundation Welcomes OpenAI As Platinum Member, Announces Donation to Rust Project
On OpenAI’s Support for Rust
Rust Foundation Member Announcement: Integer 32, Convex, Renesas, Peeriot, & Processing Foundation
Rust Commercial Network Launches to Bring Commercial Users of Rust Language Together
Rust Foundation Trusted Training Program Launches, Giving Learners a Mark of Quality to Trust
Why (& How) We Built the Rust Foundation Trusted Training Program
Welcoming Wild to the Rust Innovation Lab
Project Director Update — April & May 2026
Recap: Learning Rust from Scratch with Mainmatter at Barcelona’s First-Ever Upskilling Week
Strengthening Rust Infrastructure Security with Ubuntu Pro
Rust Foundation Trusted Training Spotlight: Mainmatter

Stats

Total words of meeting minutes written: 662k (June 2025–June 2026)

Meetings attended: 40

Total words of meeting minutes written (May): 68.1k

Average (mean) word count per team meeting:

Cargo: 2.1k
Lang triage: 3.0k
Libs-API: 5k
Leadership Council: 2.1k

Program management update — May 2026

2026-06-11T00:00:00+00:00

RustWeek and All Hands!

It finally happened. Nurzhan, Tomáš, and hundreds of Rustaceans all met up in Utrecht, the Netherlands, for RustWeek and All Hands.

RustWeek is a week-long conference organized by RustNL. It typically features two days of talks, three to four days of workshops, an unconference, and a hackathon. It's absolutely fantastic and open to everyone. The All Hands is a three-day event of team- and topic-specific sessions, bringing Project members together to meet, collaborate, resolve issues, and plan ahead. For the last two years, these events have been co-located, so most Project members got to attend both.

The dates for RustWeek 2027 are already set: May 24–29, in Utrecht again. The dates and location for the All Hands have not yet been announced.

We'll post a retrospective later, but in the meantime, it was fantastic to meet everyone.

Interviews

During the conference, the Content team recorded 12 interviews with some of the speakers and people in the Project. We got involved, too: Nurzhan was really excited (and anxious!) to meet and interview Alice Cecile (Bevy Engine) about program and project management. The interviews have been fully produced by a videographer hired from the team's budget, and they should be posted in the next month or so.

Apart from that, the team has a backlog of interviews recorded at the last Kangrejos and RustConf that is over nine months old now. They hired an editor to take care of them, so we're excited to see more interviews posted soon.

Program management

We published the final update for the 2025H2 Project goals and kicked off the new 2026 period.

We had some goals-related sessions at the All Hands and got to talk with people about their needs and experiences. There was also a discussion about funding for maintainers, which we plan to integrate into goals.

We're now working on displaying funding information (goals looking for funding, goals that are funded, etc.) on the Project Goals page. For an example, see the Funding section of the Fast Builds page.

Some other things we're looking into:

The feasibility of using goals ubiquitously instead of the current Compiler MCPs (Major Change Proposals), Library ACPs (API Change Proposals), and Language experiments.
- The Types team set a precedent for this recently by deciding to move away from MCPs in favor of goals.
Making the creation of new goals more straightforward and lightweight.
Streamlining goal updates and making them more useful.
Refactoring the tooling for managing goals.
Closer integration with the Funding team, grants, etc.

Basically, we expect goals to be opened throughout the year on a rolling basis. How do we handle that?

We have also expanded our meeting coverage. The Rustdoc team used to have chat-based meetings, but recently decided to try video calls instead and asked us to take minutes. We also reached out to the Types team, asking them to move their meeting to a nonconflicting time slot (30 minutes earlier) so that we could start attending those, too. Hopefully, this will help us keep the teams more connected.

Funding Rust maintainers

The Rust Foundation Maintainer Fund (RFMF) RFC has been merged.

The Foundation will begin raising money for the Maintainer Fund. This money will be dedicated to people doing maintenance work. This includes work such as reviewing, triaging, and large-scale refactoring, but also work that is largely invisible yet has far-reaching effects, e.g., unblocking new features.

The RFC establishes a Maintainer in Residence program (MiR — not to be confused with MIR) to provide long-term, mostly full-time support for maintainers — complementing the shorter-term Grants program.

This program was heavily inspired by Python's Developers in Residence.

The Funding team wrote about the program here, and the Foundation published a companion piece on their site.

If you're an individual, you can donate money to the Maintainer Fund via this GitHub Sponsors page. If you're a company or larger organization, reach out to maintainers-fund@rustfoundation.org. All proceeds will go directly to maintainers.

If you want to support specific people, head to the Funding page.

And last but not least, RustNL has recently hired several Rust maintainers as well. Visit their page to learn more.

Mirroring

At the All Hands, Joel Marcey distributed YubiKeys that will be used for mirror attestations. Emily, Walter, and Dirkjan put together a guide on how to use them (private for now, undergoing feedback) and verify attestation.

Arlo has practiced root signing and shared examples here.

The team discussed whether TUF is the right solution for the crates.io index. TUF was originally designed for offline signing, but the crates.io index changes very frequently and will need to be signed every minute.

The main concern was that following the TUF spec to the letter would be infeasible because it would result in too many HTTP requests. The standard seems to be moving in the right direction to solve this (they're listening to our input), but we don't want to be blocked on that.

There are options the team could consider, but they'd make crates.io incompatible with other TUF clients.

Walter said that we don't necessarily need to support other clients for the crates.io use case, and that the changes we'd need to make to rust-tuf are not substantial enough for this to be a problem.

Rustup doesn't have the same constraints, so we'll be following the spec there.

Rust for Linux

All Hands session

The Rust for Linux team was invited to the All Hands and hosted an office-hours session there. There were rustfmt and clippy representatives in the room.

Jieyou Xu wanted to clarify what exactly the Linux team needs to remove the "trailing double slash hack". The team wants this option to be stabilized at some point, but in the meantime, they would be okay with using something like RUSTC_BOOTSTRAP (which allows unstable features to be used with a stable toolchain). Rustfmt, however, does not have a way to do this today.

The team runs rustfmt in CI, but they're currently looking only for crashes (ICEs — internal compiler errors). They want to get to a place where they can catch unintentional differences in code formatting, and enforce consistent style in CI.

Alejandra González mentioned that changes to clippy are now bottlenecked by reviewers. Reviewing clippy code is complex. There are many things to check, and many edge cases to investigate. But Alejandra stressed that if someone is interested, they would be happy to teach them, and they would appreciate the help.

Recoverable integer overflow

Jana Dönszelmann opened a (draft) pull request providing a numerical overflow handler. This is something the team has wanted for a long time. Currently, Rust will panic on integer overflows (e.g. adding 1 to a u8 value of 255 — since there's no 256 in u8) in debug mode, and wrap (without panicking) in release.

The kernel needs the ability to detect overflows and react to them in some fashion. Jana's PR provides such a hook:

//@ no-prefer-dynamic
//@ compile-flags: -Coverflow-checks=recoverable
//@ run-pass
//@ check-run-results
#![feature(recoverable_integer_overflow)]
#![allow(arithmetic_overflow, unused)]

#[core::panic::integer_overflow_action]
fn overflow() {
    println!("overflow happened")
}

fn main() {
    let mut x = 255u8;
    x += 1;
}

The likely use case for this on the Linux side will be to print a kernel message the first time such a call happens (possibly tainting the kernel in the process) and keep going without spamming the log with more messages.

Tomáš's July/August absence

As a heads-up, Tomáš will be on medical leave from 2026-07-12 until 2026-08-09. There is nothing to be worried about! Nurzhan will handle the work side of things.

We put our planned time off in the PM calendar and the PM time-off Zulip thread.

Worth a look

Rust Project updates

Maintainer spotlight: Tiffany Pek Yuan (@tiif)
March 2026 Project Director Update
Launching the Rust Foundation Maintainers Fund
Announcing Rust 1.96.0
Security Advisory for Cargo (CVE-2026-5223)
Security Advisory for Cargo (CVE-2026-5222)
Project goals update — April 2026 (end of 2025H2)

Rust Foundation posts

Help Fund the People Who Build Rust
Congratulations, Walter Pearce: OpenSSF Ambassador!
Rust Foundation and Package Registry Leaders Unite to Address Open Source Sustainability Crisis

Stats

Total words of meeting minutes written: 593.9k (June 2025–May 2026)

Meetings attended: 23

Total words of meeting minutes written (May): 42.6k

Average (mean) word count per team meeting:

Cargo: 1.6k
Lang triage: 3.5k
Libs-API: 4.8k
Leadership Council: 2.6k

Project goals update — April 2026 (end of 2025H2)

2026-05-18T00:00:00+00:00

The 2025H2 Project Goal period has now concluded. Over these months, the Rust Project pursued 41 Project Goals, 13 of which were designated as Flagship Goals. This post contains curated updates on our progress since the last post and the final status for each of the goals (many of which continue as part of the 2026 period). Full details for any particular goal are available in its tracking issue.

Thanks to everyone who contributed! <3

Flagship: Beyond the &
Flagship: Flexible, fast(er) compilation
Flagship: Higher-level Rust
- Ergonomic ref-counting: RFC decision and preview
- Stabilize cargo-script
Flagship: Unblocking dormant traits
Other goal updates

Flagship: Beyond the `&`

Continue Experimentation with Pin Ergonomics

People involved: Frank King
Champions: compiler (Oliver Scherer), lang (TC)
Status: Continued

3 detailed updates available.

Frank King — comment from 2026-02-26
(Just come back from the Spring Festival)
- (locally, no PR yet): design and implement the borrow checking algorithms of &pin
- Reviewed Add Drop::pin_drop for pinned drops, to update the submodule book
- Reviewed Implement coercions between &pin (mut|const) T and &(mut) T when T: Unpin, to do some refactors according to the reviewed messages.
Frank King — comment from 2026-03-16
- Merged Implement coercions between &pin (mut|const) T and &(mut) T when T: Unpin.
- Opened draft PR Implement borrowck for &pin mut|const $place. The implementation needs to be refined and self-reviewed before the community reviews.
Frank King — comment from 2026-04-16

Self-reviewed Implement borrowck for &pin mut|const $place. Found that the current approach of handling pinned borrows may be incorrect, as it failed to distinguish a pinned borrow from a coercion of a normal-to-pinned reference. The latter doesn't prevent a T: Unpin type from being moved, but the former does, which breaks the pin coercion test.

Design a language feature to solve Field Projections

People involved: Benno Lossin
Champions: lang (Tyler Mandry)
Status: Continued

5 detailed updates available.

Benno Lossin — comment from 2026-01-01
- At the beginning of December, we set out to answer five important questions regarding the virtual places approach. We discussed four questions and arrived at answers for three.
  - The first question we looked at was question 3 Canonical Projections.
  - Next we looked at question 4 Non-Indirected Containers.
  - As the final question we answered, we looked at question 1 Field-by-Field Projections vs One-Shot Projections.
  - At the moment, we are investigating question 2 and I wrote a blog post with a potential solution that still needs feedback.
- We started a Wiki Project to consolidate our knowledge in one place.
  - We implemented an algorithm to determine the type of a place expression.
- Our plan is to continue this project goal in the next goal period.
Benno Lossin — comment from 2026-01-25

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.

Benno Lossin — comment from 2026-02-28

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:
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):
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)

Benno Lossin — comment from 2026-03-20
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. 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.
Benno Lossin — comment from 2026-04-02
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.

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:
Thanks to everyone who participated in the meeting!

Reborrow traits

People involved: Aapo Alasuutari
Champions: compiler (Oliver Scherer), lang (Tyler Mandry)
Status: Continued

1 detailed update available.

Aapo Alasuutari — comment from 2026-02-28
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:
```
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:
```
#[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.

Flagship: Flexible, fast(er) compilation

build-std

People involved: David Wood, Adam Gemmell
Champions: cargo (Eric Huss), compiler (David Wood), libs (Amanieu d'Antras)
Status: Continued

4 detailed updates available.

David Wood — comment from 2026-01-15

rust-lang/rfcs#3873 has been merged and an FCP has been started on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 - those both have some feedback for me to respond to that I'll get to as soon as I can.
David Wood — comment from 2026-02-17

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.
David Wood — comment from 2026-03-17

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.
David Wood — comment from 2026-04-14

rust-lang/rfcs#3874 has finished FCP and is due to be merged any day now. I'm working on resolving the remaining open comments on rust-lang/rfcs#3875 and then intend to nudge the reviewers to have a look and check their boxes or leave concerns.

Adam Gemmell has opened rust-lang/cargo#16675 with an early sketch of some of the core changes that build-std would require and is working with the Cargo team to address feedback and work out how to proceed with the implementation.

Production-ready cranelift backend

People involved: Folkert de Vries, bjorn3, Trifecta Tech Foundation
Champions: compiler (bjorn3)
Status: Not completed (lack of funding)

Promoting Parallel Front End

People involved: Sparrow Li
Status: Continued

Relink don't Rebuild

People involved: Jane Lusby, @dropbear32, @osiewicz
Champions: cargo (Weihang Lo), compiler (Oliver Scherer)
Status: Not completed (note)

Flagship: Higher-level Rust

Ergonomic ref-counting: RFC decision and preview

People involved: Niko Matsakis, Santiago Pastorino
Champions: compiler (Santiago Pastorino), lang (Niko Matsakis)
Status: Continued

Stabilize cargo-script

People involved: Ed Page
Champions: cargo (Ed Page), lang (Josh Triplett), lang-docs (Josh Triplett)
Status: Continued

3 detailed updates available.

Ed Page — comment from 2026-01-14
#146377 has been decided and merged.

Blockers
- T-lang discussing CR / text direction feedback: comment
- T-rustdoc deciding on and implementing how they want frontmatter handled in doctests
Ed Page — comment from 2026-02-13
- FCP has ended on frontmatter support, just awaiting merge
- Cargo script has entered FCP
Blockers
- Potential issues around edition, see Cargo script edition policy (lang/edition aspects).
Ed Page — comment from 2026-03-16
Cargo's FCP has ended.

Blockers
- Cargo script edition policy (lang/edition aspects)

Flagship: Unblocking dormant traits

Evolving trait hierarchies

People involved: Taylor Cramer and others
Champions: lang (Taylor Cramer), types (Oliver Scherer)
Status: Superseded by the Implement Supertrait auto impl and Arbitrary Self Types 2026 goals

In-place initialization

People involved: Alice Ryhl, Benno Lossin, Michael Goulet, Taylor Cramer, Josh Triplett, Gary Guo, Yoshua Wuyts
Champions: lang (Taylor Cramer)
Status: Continued

1 detailed update available.

Alice Ryhl — comment from 2026-01-31

A proposal to continue this goal in the next goal period was merged.

Next-generation trait solver

People involved: lcnr, Boxy, Michael Goulet
Champions: types (lcnr)
Status: Continued

1 detailed update available.

lcnr — comment from 2026-01-19

There hasn't been too much progress over the last few weeks and I've been mostly taking a Christmas break. Nicholas Nethercote has been looking into the performance of the new trait solver, cleaning up canonicalization and slightly improving its performance: PR 1 and PR 2.

Shoyu Vanilla looked into ICE from mir validation on unsizing in opendal and uncovered the underlying bug there. While this issue also affects the old solver and the proper fix for it requires where-bounds on binders, we can work around this bug in the trait solver for now and intend to do so.

We've started another crater run with all our recent changes and adwin has started to triage it, uncovering one new issue up until now. Intend to continue going through that over the next few weeks.

There's also a lot in-progress work going on. I am collaborating with Niko Matsakis to specify and later RFC the cycle semantics of Rust. León Orell Valerian Liehr is working on a replacement for the rustdoc's auto trait impl synthesis. tiif is working on a fix a MIR borrowck unsoundness. Shoyu Vanilla and I are improving the way we propagate inference constraints from the expected return type to function arguments, fixing this issue.

Stabilizable Polonius support on nightly

People involved: Rémy Rakic, Amanda Stjerna, Niko Matsakis
Champions: types (Jack Huey)
Status: Continued

2 detailed updates available.

Rémy Rakic — comment from 2026-01-30
This month's update:
- tiif is making progress on normalizing opaques while computing implied bounds
- we discussed how to investigate and fix the remaining correctness issues in Tage's work, to be able to evaluate it more accurately: in particular around variance and bidirectional edges, and without the reliance on NLL (having computed region values / errors)
- we've tried to see if it'd be possible to remove the cfg region elements
- Amanda is still working on her two papers, one about the current borrow checker and one about the work on Polonius. Her major PR for the restructuring of placeholder handling during region inference is stalled due to a conflict with further trait solver developments and may have to be abandoned. Work with the larger types team is ongoing and smaller patches/refactorings/improvements are being landed in the meantime.
- #149639 has now landed, and #150551 is still in review
- I've also fixed more small inefficiencies (computing boring/relevant locals on-demand in diagnostics, removed conversions between locations and points, etc) building on top of the previous PRs (so they need to be reviewed first)
- I've looked at crates.io again with the alpha, to find functions that are slower than with NLLs. AFAICT the worst case there is 60% for a 5KLOC function with 42K loans, 255K statements, and 125K outlives constraints. I'll see what we can do with this. Small composable functions is still good advice.
- there seem to be optimization opportunities to 1. limit propagation to the smaller number of blocks that could be affected by bidirectional edges, 2. for unifying invariant lifetimes of live locals that are assigned at most once (à la use-def chains), 3. for invalidations that are just the activation of a reservation
- we discussed possible plans to gather actual statistics, using the infrastructure that was created for the Metrics project
- we're also preparing the new project goal for this year, where we'll want to stabilize the alpha 🤞
Rémy Rakic — comment from 2026-02-28
We had a bit less time this month, the update will be shorter, but still meaningful I hope:
- #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 #152051, and a-mir-formality work with Niko and I.
- Amanda has opened a few cleanup PRs (#152438, and #152579), and #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 #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 #152587.

Other goal updates

Add a team charter for rustdoc team

People involved: Guillaume Gomez
Champions: rustdoc (Guillaume Gomez)
Status: Completed

Borrow checking in a-mir-formality

People involved: Niko Matsakis, tiif
Champions: types (Niko Matsakis)
Status: Continued

C++/Rust Interop Problem Space Mapping

People involved: Joel Marcey
Champions: compiler (Oliver Scherer), lang (Tyler Mandry), libs (David Tolnay)
Status: Continued

5 detailed updates available.

Joel Marcey — comment from 2026-01-20

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.
Joel Marcey — comment from 2026-01-31

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.
teor — comment from 2026-02-27
Hi, I'm the new contractor on the interop problem space mapping project goal.

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
Next step is prioritising a few of the use cases, then working on related problem statements in more detail.

Blockers

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

Help wanted

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.

I'll post an update here every few weeks, you can follow more detailed weekly updates on Zulip.
teor — comment from 2026-03-30
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 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.

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.

Blockers

Nothing at the moment, everyone has been extremely helpful, and I'm getting good feedback on use cases, problems, priorities, and Rust language experiments.
teor — comment from 2026-05-01
In the last month, I've:
- prepared for RustWeek and the All Hands, where I will be giving a Rust Project track talk and running an All Hands interop session (schedule TBC)
- added new interop use cases and problem statements, and continued categorising them using GitHub tags
- continued to expand the draft high-level problem statement summaries
- added interop code examples, including many examples from Outreachy applicants
- continued mentoring Outreachy applicants
- continued working on the Overloading Rust language experiment
Specifically, the last month we've made detailed progress on two high-priority use cases:
- calling an overloaded C++ function from Rust, with a Rust lang experiment - implementation discussion
  - we've merged a refactor to prepare for this experiment, which gave some nice perf wins
  - the initial overloading experiment PR has been through two rounds of review, and is waiting for my revisions and rebasing
- adding Rust to an existing C++ build system
  - Outreachy applicants wrote interop example code PRs
  - these interop user experiences are waiting for analysis, so they can be summarised in the build system and overloading problem statements
  - this will likely happen after RustWeek and the All Hands
Next step is continuing to work on the overloading experiment, along with RustWeek/All Hands preparation, and collecting feedback during the conference.

Blockers

Nothing at the moment. There is a steady stream of new use cases, problems, code examples and Rust language experiment feedback.

Comprehensive niche checks for Rust

People involved: Bastian Kersting, Jakob Koschel
Champions: compiler (Ben Kimock), opsem (Ben Kimock)
Status: Not completed

Const Generics

People involved: Boxy, Noah Lev
Champions: lang (Niko Matsakis)
Status: Continued

6 detailed updates available.

Niko Matsakis — comment from 2026-01-27

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

#[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!

Boxy — comment from 2026-01-30
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 @ 💬
Niko Matsakis — comment from 2026-02-13

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.
Boxy — comment from 2026-02-28

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.
Boxy — comment from 2026-04-02

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".
Boxy — comment from 2026-05-01

started running weekly meetings about const generics to make it easier to keep up to date with all the people who are working on const generics stuff. i think min_adt_const_params is now at the point of what the RFC is going to specify.

GCA is making good progress thanks to ashley's work. i also met with lcnr where we talked about whether there was some version of mGCA that is stabilizeable in the near future or not (maybe!)

Continue resolving `cargo-semver-checks` blockers for merging into cargo

People involved: Predrag Gruevski
Champions: cargo (Ed Page), rustdoc (Alona Enraght-Moony)
Status: Continued

1 detailed update available.

Predrag Gruevski — comment from 2026-01-17

I posted a "year in review" for cargo-semver-checks.

It has a section on how I think we should move forward in 2026 and beyond.

Develop the capabilities to keep the FLS up to date

People involved: Pete LeVasseur, t-spec, and contributors from Ferrous Systems
Champions: bootstrap (Jakub Beránek), lang (Niko Matsakis), spec (Pete LeVasseur)
Status: Superseded by the Stabilize FLS Release Cadence 2026 goal

2 detailed updates available.

Pete LeVasseur — comment from 2026-03-04

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.

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.
Pete LeVasseur — comment from 2026-04-02
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

Emit Retags in Codegen

People involved: Ian McCormack
Champions: compiler (Ralf Jung), opsem (Ralf Jung)
Status: Superseded by the BorrowSanitizer 2026 goal

4 detailed updates available.

Ian McCormack — comment from 2026-01-09
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.
Ian McCormack — comment from 2026-02-24
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.
Ian McCormack — comment from 2026-03-30
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.
Ian McCormack — comment from 2026-04-29
We have some exciting news: our talk on BorrowSanitizer was accepted at RustConf this year! We’re grateful for the opportunity and looking forward to sharing our results with the broader community this September.

We just posted our April status update. It’s a bit of a technical one. Here’s the TL;DR:
- BorrowSanitizer now uses a shadow stack to track metadata at runtime - this is a significantly different strategy than other LLVM sanitizers, and it will help us support garbage collection.
- We are now ready to start sending in PRs for our retag intrinsics. It will take a little time to split our changes up into meaningful, reviewable chunks—you can expect to see these throughout the next week.
The RFC for our LLVM components is taking a little longer than expected, but it was worth taking the extra time to test out compiler changes and make sure that we had the core parts of the instrumentation pass settled. We’ll be drafting the RFC throughout the next few weeks.

Expand the Rust Reference to specify more aspects of the Rust language

People involved: Josh Triplett, Amanieu d'Antras, Guillaume Gomez, Jack Huey, lcnr, Mara Bos, Vadim Petrochenkov, Jane Lusby
Champions: lang-docs (Josh Triplett), spec (Josh Triplett)
Status: Superseded by the Experimental language specification 2026 goal

1 detailed update available.

Josh Triplett — comment from 2026-04-14

This work is now continuing into a new goal by Jack Huey.

Finish the libtest json output experiment

People involved: Ed Page
Champions: cargo (Ed Page)
Status: Continued

Finish the std::offload module

People involved: Manuel Drehwald, LLVM offload/GPU contributors
Champions: compiler (Manuel Drehwald), lang (TC)
Status: Superseded by the High-Level ML optimizations 2026 goal

2 detailed updates available.

Manuel Drehwald — comment from 2026-01-16
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. 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 bootstrapping logic, and as part of that start building offload in CI.
Manuel Drehwald — comment from 2026-04-01

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!

Getting Rust for Linux into stable Rust: compiler features

People involved: Tomas Sedovic, compiler contributors
Champions: compiler (Wesley Wiser)
Status: Continued

4 detailed updates available.

Tomas Sedovic — comment from 2026-01-16

Update from the 2026-01-14 meeting:

#![register_tool] rust#66079

Tyler Mandry proposed FCP of the RFC#3808 and nominated it for a Lang discussion.

-Zdebuginfo-compression rust#120953

Wesley Wiser proposed stabilization: rust#150625.

Josh Triplett suggested trying to bring zlib-rs in the kernel as a case study.

-Zdirect-access-external-data rust#127488

rust#150494 was merged two days ago, what reminds is updating the documentation and stabilizing the feature.

There's an ongoing discussion about the feature on the Rust Zulip as well.
Tomas Sedovic — comment from 2026-02-17

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

-Zdirect-access-external-data rust#127488

Gary Guo's fix PR was merged.

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

Improving objtool's handling of noreturn is on Gary Guo's radar but there wasn't time yet.
Tomas Sedovic — comment from 2026-03-16

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 allowing forbidden target features to be hard errors, which the -Zharden-sls patch should be rebased on top of.

#![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.
Tomas Sedovic — comment from 2026-04-10

Update from the 2026-04-08 meeting:

-Zsanitize=kernel-hwaddress

rust#153049 is merged. What remains of the tracking issue rust#154171 is a few docs checklists.

Alice Ryhl added the unstable book doc changes in the PR itself and Wesley Wiser confirmed that's all the documentation needed for sanitizers.

Getting Rust for Linux into stable Rust: language features

People involved: Tomas Sedovic, Ding Xiang Fei
Champions: lang (Josh Triplett), lang-docs (TC)
Status: Superseded by the Rust for Linux 2026 roadmap

6 detailed updates available.

Tomas Sedovic — comment from 2026-01-19

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.

Field Projections goal#390

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

Tyler opened a Beyond References wiki to keep all the proposals, resources in one place.

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 the Beyond References wiki.

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 replaceable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion.
Tomas Sedovic — comment from 2026-02-16

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 represent 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.
Tomas Sedovic — comment from 2026-03-11

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.
Tomas Sedovic — comment from 2026-03-16

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.

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.
Tomas Sedovic — comment from 2026-03-26
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.

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.
Tomas Sedovic — comment from 2026-04-10

Update from the 2026-04-08 meeting:

zerocopy features in Rust's std

zerocopy uses two traits that are both polyfills for unstable traits : KnownLayout (for ptr_metadata) and Immutable (for Freeze). It would help maintenance of zerocopy (which Rust for Linux plans to start using) if these were stabilised.

ptr_metadata is something the team wants in the kernel independently. It's possibly blocked on (or at least might have interactions with) the Sized Hierarchy work.

Freeze (now NoCell) has an RFC.

Deref/Receiver

Jack Huey started reviewing Ding Xiang Fei's PR to split the autoderef chain and feels it's not ready to go in front of the full Lang team.

We also discussed the dependence/independence of the Deref and Receiver implementations, in particular whether it ever makes sense to implement Deref but not Receiver. Josh Triplett suggested gathering examples for cases like that (where you can't use the type as a Self type in the function declaration, but allow calling methods on it).

The current plan for the experiment is to have these traits separate, but have the compiler enforce that if they implement the same type, their targets are identical. This will let us open the door for any future possibilities (a supertrait / subtrait relation, or having diverging targets in the future).

We want to experiment to see where and how these traits and their possible evolution might be helpful.

null-ptr-deref

The team would like to have a (an optional) compiler guarantee, that the compiler never removes null checks on raw pointers. What can currently happen in C is that if you deref a null pointer, the compiler can do optimisations including removing any subsequent checks whether that pointer is null, because dereferencing a null pointer is undefined behaviour.

But the null check can still help prevent further bugs and in C, the kernel now disables the optimisation that would remove it.

Miguel Ojeda is going to open an MCP for this.

In-Place Initialization

Benno Lossin opened a proposal for an in-person room at the 2026 All Hands for In-place initialization.

Here's a meta issue tracking all the proposals and discussions about the feature.

The design space is complex and the team hopes that discussing it in person will help move it forward.

Implement Open API Namespace Support

People involved: Ed Page, b-naber
Champions: cargo (Ed Page), compiler (b-naber), crates-io (Carol Nichols)
Status: Continued

MIR move elimination

People involved: Amanieu d'Antras
Champions: lang (Amanieu d'Antras)
Status: Continued

1 detailed update available.

Amanieu d'Antras — comment from 2026-04-03
The RFC has just been published. 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.

Prototype a new set of Cargo "plumbing" commands

People involved: Ed Page
Champions: cargo (Ed Page)
Status: Continued

Prototype Cargo build analysis

People involved: Weihang Lo
Champions: cargo (Weihang Lo)
Status: Completed

1 detailed update available.

Weihang Lo — comment from 2026-01-08
The prototype of this project goal is basically complete.

Current state

This project goal introduces build analysis support in Cargo, with the aim of making build behavior understandable across multiple invocations, not just a single run.

At a high level, the prototype:
- Records build metadata over time, including:
  - rebuild reasons
  - timing information
  - relevant invocation context
- Stores this data locally in a structured log format suitable for later analysis
- Exposes the data via unstable cargo report subcommands, such as:
  - cargo report sessions - list session IDs
  - cargo report timings - HTML timing report
  - cargo report rebuilds - Why things rebuilt
See the Reference for a more thorough usage documentation

Path towards stabilization

Before this feature can be stabilized, the following unresolved questions must be answered. They might not block stabilization, but need to be evaluated if it is fine to leave for future.

cargo report commands

This is a stabilization blocker.
- Currently all three report commands (sessions, rebuilds, timings) implicitly inspect global log files when if not in a workspace.
  - Should this be explicit with a flag?
  - Should this be an error if not in a workspace?
- Bikeshed on command names
  - Currently we have all nouns
    - For sessions
      
      runs simple but ambiguous
      
      Just log like git log
      
      history user-friendly (docker history, shell history, though not alike)
    - For timings:
      
      Not controversial, as we have --timings flag already
    - For rebuilds:
      
      rebuild-reasons more explicit
  - Or move to action-oriented verbs:
  - cargo report list-sessions
  - cargo report analyze-timings (bazel analyze-profile)
  - cargo report explain-rebuilds
  - Or question-oriented verbs:
  - cargo report what-ran more general (buck2 log what-ran)
  - cargo report why-rebuilt/why-reran
cargo report sessions
- Currently it prints a human-readable output without a format for programmable use cases.
  - Should we provide a programmable output (for example behind --message-format=json)?
cargo report rebuilds
- Extend the report from fingerprint to new hash (-Cmetadata/-Cextra-filename)
  - We currently can't distinguish whether a fresh build is a real new build or just rustflags changed
  - https://github.com/rust-lang/cargo/pull/16456#discussion_r2662364819
- Make each rebuilt reason more actionable and friendly for end-users.
- Should we log the fingerprint values being compared, or just the diff result?
- #t-cargo > logging unit fingerprint @ 💬
Log message schema

This is a stabilization blocker.
- Providing types for reading log messages
  - We should export LogMessage enum and related types in cargo-util-schemas
  - Users may want to parse logs programmatically
  - https://github.com/rust-lang/cargo/pull/16150#discussion_r2462065538
- JSON schema evolution and versioning
  - Should we version the schema explicitly in each message?
  - Compatibility might be the same as https://doc.rust-lang.org/nightly/cargo/commands/cargo-metadata.html?highlight=compa#compatibility
- Message structure consistency
  - Current log messages deviate from cargo's normal JSON message structure
  - Should we align with existing cargo JSON output format, for example the target field?
  - https://github.com/rust-lang/cargo/pull/16414#discussion_r2632724893
  - https://github.com/rust-lang/cargo/pull/16303#discussion_r2565526807
  - https://github.com/rust-lang/cargo/pull/16303#discussion_r2561862478
- Should we expose the entire DirtyReason enum as-is?
  - Currently exposes internal implementation details
  - May want to create a separate public-facing enum
  - Need to decide which variants are user-facing vs internal
- Check usefulness of each variant
  - Some variants may be obsolete (e.g., RustflagsChanged may be rare after -Cmetadata changes)
  - Need audit of which variants actually occur in practice
  - Remove or consolidate rarely-used variants
- Make dirty reasons end-user friendly
  - Current reasons are technical (e.g., "local fingerprint type changed")
  - Users need actionable messages (e.g., "file modified: src/lib.rs")
- Expose target and mode
  - Are they universal for all kind of units? We might want to rename mode to action, as an action kind of a unit.
  - https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20analysis.20log.20format/near/564781487
Log infrastructure

These are mostly future possibilities, not a stabilization blocker, as it is highly possible to do incremental improvements.
- log compression https://github.com/rust-lang/cargo/issues/16475
- log rotation https://github.com/rust-lang/cargo/issues/16471
- Is losing data on crashes ok? https://github.com/rust-lang/cargo/pull//16150#discussion_r2462056940
See also https://github.com/rust-lang/cargo/issues/16471#issuecomment-3724915770

Nested Cargo calls

See https://github.com/rust-lang/cargo/issues/16477.

Basically, we need to have a way to associate log files of nested Cargo calls. That helps other tools as well as cargo fix itself.

This is a stabilization blocker.

How contributors can help

Future contributors can help by:
- picking up any linked issues below or in https://github.com/rust-lang/cargo/issues/15844
- building external tools utilizing the log messages, and providing feedback
- providing real-world feedback from large or unusual builds
A series of follow-up tasks has been cut to track remaining work:
- https://github.com/rust-lang/cargo/issues/16470
- https://github.com/rust-lang/cargo/issues/16471
- https://github.com/rust-lang/cargo/issues/16472
- https://github.com/rust-lang/cargo/issues/16473
- https://github.com/rust-lang/cargo/issues/16474
- https://github.com/rust-lang/cargo/issues/16475
- https://github.com/rust-lang/cargo/issues/16477
- https://github.com/rust-lang/cargo/issues/16488

reflection and comptime

People involved: Oliver Scherer
Champions: compiler (Oliver Scherer), lang (Scott McMurray), libs (Josh Triplett)
Status: Continued

5 detailed updates available.

Oliver Scherer — comment from 2026-01-14
- The MVP 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.
- try_as_dyn and try_as_dyn_mut have landed, and I'm working on removing the 'static requirement.
Oliver Scherer — comment from 2026-02-09
- @BD103 added Type::of for unsized types and support for slices, arrays, and raw pointer
- Asuna added all of our primitives
- Jamie Hill-Daniel gave us references
- @izagawd made it possible to extract some info from dyn Trait
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)
Oliver Scherer — comment from 2026-03-19
- I added support for getting reflection information of any type, not just 'static ones
- 9SonSteroids added a function pointer MVP and trait object support
- Asuna added basic struct/enum/union support
Oliver Scherer — comment from 2026-04-22

No changes since last time.

I'm writing a document for the lang team meeting on reflection next week
Oliver Scherer — comment from 2026-04-22
Help wanted
- add more information to adts (e.g. doc comments, attributes, ...), whatever else is usually used by crates like bevy-reflect
- need to make struct field reflection respect privacy

Rework Cargo Build Dir Layout

People involved: Ross Sullivan
Champions: cargo (Weihang Lo)
Status: Completed; the Cargo cross workspace cache 2026 goal will build on this work

2 detailed updates available.

Ross Sullivan — comment from 2026-01-15

Fine grain locking for build-dir was merged and now available on nightly via -Zfine-grain-locking unstable flag. 🎉

There are some known issues we'd like to address before doing a formal call for testing. Notably, improving blocking messages, fixing potential thread starvation in Cargo's job queue when locks block, and investigate increasing rlimits to reduce risk of hitting max file descriptors for large projects.

I am hopeful that these issues will be resolved over the coming month and we can do a call for testing to start gathering feedback from the community on whether the new locking strategy improves workflows.
Ross Sullivan — comment from 2026-03-09

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 #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. (#16542, #16502, #16515, #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.

Run more tests for GCC backend in the Rust's CI

People involved: Guillaume Gomez
Champions: compiler (Wesley Wiser), infra (Marco Ieni)
Status: Completed

Rust Stabilization of MemorySanitizer and ThreadSanitizer Support

People involved: Jakob Koschel, Bastian Kersting
Status: Continued

3 detailed updates available.

Jakob Koschel — comment from 2026-01-14

The MCP has been seconded and is still waiting 3 days to be approved. Once that is done, we can proceed with merging the Tier 2 target.
Jakob Koschel — comment from 2026-02-16

Both the MCP and the PR for the AddressSanitizer target have been merged. Next up I should prepare the MCP for the Memory- and ThreadSanitizer targets, hopefully sending out soon.
Jakob Koschel — comment from 2026-03-31

The targets for MSan and TSan are merged now.

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

Rust Vision Document

People involved: Niko Matsakis, vision team
Status: Partially completed; work continues outside of Project Goals

rustc-perf improvements

People involved: James Barford, Jakub Beránek, David Wood
Champions: compiler (David Wood), infra (Jakub Beránek)
Status: Technical work completed; remaining policy and infrastructure work postponed

Stabilize public/private dependencies

People involved: Ed Page
Champions: cargo (Ed Page)
Status: Continued

Stabilize rustdoc `doc_cfg` feature

People involved: Guillaume Gomez
Champions: rustdoc (Guillaume Gomez)
Status: Not completed (blocked)

SVE and SME on AArch64

People involved: David Wood
Champions: compiler (David Wood), lang (Niko Matsakis), libs (Amanieu d'Antras)
Status: Continued

5 detailed updates available.

David Wood — comment from 2026-01-15

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
David Wood — comment from 2026-02-17

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.
David Wood — comment from 2026-03-17

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.
David Wood — comment from 2026-03-17

Per last comment, rust-lang/rfcs#3729 has been updated
David Wood — comment from 2026-04-14

For the scalable vector half of the goal, we've landed a bunch of compiler fixes - rust-lang/rust#153286, rust-lang/rust#153608, rust-lang/rust#154850, rust-lang/rust#154950, rust-lang/rust#155106 and rust-lang/rust#155243 - and opened our stdarch patch with intrinsics - rust-lang/stdarch#2071. That patch should be passing CI tomorrow once nightly updates to fix an unrelated spurious CI failure. We've got a handful of follow-ups to do afterwards, listed on rust-lang/rust#145052.

For the sized hierarchy half of the goal, Rémy Rakic and I had two design meetings with the language team (2026/03/18 and 2026/03/25) discussing the syntax/naming and migration strategy respectively.

On syntax, the language team preferred introducing an "only bounds" syntax to control opting-out of default bounds and opting-in to alternative bounds in a family of traits (described in an alternative in the RFC), but there was an open question of whether that syntax should apply to an individual bound or all of the bounds - Niko Matsakis is investigating that.

On naming, the language team also preferred the name SizeOfVal over MetaSized, and didn't like Pointee but had no better alternatives. Rémy Rakic prepared rust-lang/rust#154374 to do that renaming and started a discussion with the library team to confirm they were happy with the name, because changing it involves an amount of churn. The library team wanted to know what other traits in the hierarchy might later be introduced, as that would help inform the naming of the currently proposed traits, so Rémy Rakic wrote up a document with that information. We're holding off on doing any name changes until we find some consensus between libs and lang - who is responsible for these traits' names is a bit unclear.

On migration, the language team were largely happy with our proposed approach, and we realised that the approach proposed by lcnr for associated types might also work for our other migrations. Rémy Rakic has had meetings with lcnr to better understand that approach and to work out the next steps for implementing it.

Type System Documentation

People involved: Boxy, lcnr
Champions: types (Boxy)
Status: Continued

Unsafe Fields

People involved: Jack Wrenn, Jacob Pratt, Luca Versari
Champions: compiler (Jack Wrenn), lang (Scott McMurray)
Status: Continued

2 detailed updates available.

Jack Wrenn — comment from 2026-02-18

RFC has been accepted. I'm preparing a 2026 continuing goal for stabilization.
Jack Wrenn — comment from 2026-04-14

Opened PR (#16767(https://github.com/rust-lang/rust-clippy/pull/16767)) extending Clippy support to unsafe fields.

Blockers

Waiting for t-clippy to review #16767(https://github.com/rust-lang/rust-clippy/pull/16767).

Program management update — April 2026

2026-05-13T00:00:00+00:00

Greetings! This was a busy month. The Project goals RFC has been accepted, and we're officially in the 2026 goals period. At the time of writing, RustWeek is exactly one week away. Time flies!

Program management schedule

Nurzhan and Tomáš have settled on our meeting schedule. Roughly speaking, we're taking turns attending each meeting, and we've set it up to reduce the number of back-to-back meetings and long evenings. We're also getting some call-free Fridays, which is always nice.

The calendar is publicly accessible and we keep it up to date.

The 2026 RustWeek / All Hands

In the week of 18th May, Utrecht will briefly become a city with the highest per-capita Rustacean concentration. Just like last year, it will host the co-located RustWeek and Rust All Hands conferences!

The pre-registration and workshops will start on Monday, with the actual RustWeek conference on Tuesday and Wednesday, followed by three days of the All Hands.

Have a look at the speakers, schedule, check out the website for more information, and if you plan to go, don't forget to buy a ticket.

The two of us plan to be there. Feel free to say hi!

Project goals

The 2026 Project goals RFC has been accepted! This happened about a month later than we planned. We'll keep that in mind for next year, and as most of the Project goals team members are going to be at the All Hands, we plan to do a retrospective there.

All the new tracking issues have been created, and the continuing ones have been updated too. Any goals that weren't renewed for 2026 are now closed.

If you're a point of contact on a goal, you will start getting bot messages reminding you to post an update on the tracking issue. These reminders happen roughly twice a month and won't trigger for you if you've already posted an update recently.

Now that the RFC is merged, we'll publish one last 2025h2 Project goals update blog post. Then (possibly kicking things off at the All Hands again), we'll plan how we'll be doing updates going forward. People brought up several issues with the current way the posts are formatted, the information they show, and whether they're useful at all.

Outreachy

Throughout April, the Outreachy internship applicants were getting set up and started sending their contributions. A few days ago, the organizers selected four interns.

These are the projects our interns signed up for:

Calling overloaded C++ functions from Rust.
Code coverage of the Rust compiler at scale.
Fuzzing the a-mir-formality type system implementation.
Improve the security of GitHub Actions of the Rust Project.

You can read more about the projects and Outreachy in general in Jack Huey's blog post.

The interns will work on these projects over the next three months. Congratulations to the selected interns and huge thanks to Jack, the mentors, and everyone else who participated <3.

Exciting times ahead!

C++ interop update

In February 2026, the Foundation hired teor to speed up the mapping of the interop problem space, and their work continues apace.

teor has been posting monthly updates on the C++ interop Project goal tracker and weekly ones on Zulip.

We now have around 30 interop problem statements and use cases listed in the interop-initiative repo. If you're at all interested in this, do check it out. The problem statements are really well-described, include example code, and link to prior art.

Here is a string interop example.

As part of the contribution round, the Outreachy applicants provided executable code samples, e.g., calling overloaded C++ functions from Rust.

teor also started a lang experiment to implement the splat feature. This will provide a way to define function overloading and variable arguments in Rust. The initial focus is to improve interoperability with C++, which does allow both.

In addition to this work showing direct impact, Joel Marcey published an update on the Rust Foundation Interop Initiative. The post goes over the initiative's accomplishments. These include working with ISO WG21 (the committee responsible for C++ standardization). There seems to be a strong consensus for providing memory safety mechanisms to C++, but this will take multiple years.

So the Foundation is now focusing more on the immediate needs of projects with large C++ codebases who want to (or already started to) adopt Rust. This is where all the work teor's been doing comes in.

Content team

The last few months have been difficult for the team to dedicate time to producing useful content for everyone. We've published a couple of interviews (Daniel Almeida on a Rust GPU driver in Linux and Tyler Mandry on C++/Rust interop), and a Rust 1.95 changelog overview, but we have a backlog of another nine recordings in the pipeline.

A lot of the folks will also be at the All Hands, and we're planning to do more interviews there.

What became clear is that the volunteering contribution model that works for code, documentation, etc., is less successful when it comes to things like recording and editing video. We're able to do this (as demonstrated by what we already put out), but the time commitment is really high compared to what a professional could do, even at the lowest level of effort.

To that end, TC proposed a 2026 funding request to the Council. In it, we asked for $15,000 USD to hire an editor who would process our existing backlog as well as videographers for the events where we'll conduct the bulk of our upcoming interviews (All Hands and RustConf).

The Council has approved this request, and we're now in talks with people we might hire.

This would let us focus on utilizing our knowledge and connections to interview great people and share their thoughts with the rest of the community.

Rust for Linux

A lot of the Rust for Linux folks will attend RustWeek and/or the All Hands. The Rust Project also extended an invitation to the kernel developers, and some of them will be there too.

The project will hold a few sessions at the All Hands: In-place Initialization, Field Projections, CoccinelleForRust, Compiling Rust to BPF, and office hours.

We continued having our regular fortnightly meetings; here's what we discussed in April:

zerocopy features in std

Given the plan to include zerocopy in Linux, the team brought up the possibility of stabilizing a few unstable pieces of the standard library that zerocopy ends up re-implementing.

These are ptr_metadata and Freeze. Having these in would help with the zerocopy maintenance.

Freeze now has an open RFC as core::marker::NoCell, while ptr_metadata is blocked on Sized Hierarchy.

null-ptr-deref

The team would like to have an (optional) guarantee that the compiler will never remove null checks on raw pointers. In C, dereferencing a null pointer is undefined behavior, so the compiler may optimize away subsequent null checks against that pointer. However, the null check can still serve as a safeguard against other bugs, and in C, the kernel now disables the optimization that would remove it.

Edition migration tooling

The team wants to move to the new edition, as it would fix some existing bugs and provide nicer language and library APIs. However, they're concerned about situations where the same code has different semantics in different editions.

Making semantic changes is something that the language explicitly allows, and while we provide tooling to migrate or at least highlight these cases to prevent breakages, this tooling cannot guarantee catching 100% of the issues.

A challenge with the current approach is that when the kernel migrates to a new edition, the previous releases will stay on older editions (potentially more than one), and these situations can be really easy to miss when backporting a change. Anything that changes the drop order (e.g., the if let temporary scope change in the 2024 edition) could result in undefined behavior (UB).

Miguel Ojeda brought this up to check on what guarantees the language and tooling make. They're looking for a way to flag cases where the same code has different semantics with a zero false negative rate (i.e., it will not let something slip by).

TC explained that the current migration tooling (edition lints and cargo fix) is not set up to make this a guarantee, although we try to get as close as possible and put a lot of effort into migration testing.

Benno Lossin suggested writing tooling that would compile the code being evaluated under both editions and compare the MIR output. If they're identical, no semantic changes occurred. Otherwise, there may or may not be changes. This risks generating false positives, but at least the reviewers can be confident that nothing has been silently accepted. This seems feasible and might be something the Project would be interested in adopting and maintaining, but there's no bandwidth to do this within the edition team.

Interestingly, the edition migration itself isn't an issue—the Rust for Linux team pays attention to the edition migration guide and checks things. The main issue is with backports, which are semi-automatic. If a patch is flagged for a backport and it applies cleanly, there's little human supervision involved. When the backport patch (coming from a newer edition) uses new features, compilation fails on the older edition, flagging people to pay attention. However, when the code looks identical in both editions but behaves differently, we may run into issues.

In the end, several options were proposed, each with its own trade-offs:

Stay on an edition until all the stable branches move to a MSRV (minimal supported Rust version) that allows migrating to a new edition wholesale.
Develop an outside tool that would compile the code in both editions and check whether they produce the same MIR.
Develop review processes for backporting patches on the kernel side to handle these cases.
Develop processes and tooling within the kernel for writing all code such that it always falls within the intersection between all editions supported on all branches.

This is a topic we will almost certainly come back to.

Project Director election process update

In autumn 2025, Tomáš facilitated the Project Director election. A part of the facilitator role is to publish a retrospective, clarify the documentation, and propose changes to the election process (if relevant).

This is the 2025 PD election retrospective. The PR that clarifies the election processes is here.

Worth a look

Rust Foundation posts

Announcing the 2026 Rust-Edu Refresh and CFP
Project Director Update — March 2026
Welcoming Symposium to the Rust Innovation Lab
RustConf 2026: Speakers Announced, Registration Open
- Tomáš, one of our PMs, is among the speakers, sharing the progress on the Rust in CPython initiative.
Rust Foundation Interop Initiative Update: From Research to Implementation
Rust Foundation and Package Registry Leaders Unite to Address Open Source Sustainability Crisis

Rust Project updates

Raising the baseline for the nvptx64-nvidia-cuda target
Announcing Google Summer of Code 2026 selected projects
Announcing Rust 1.95.0
- Check out the accompanying Release Changelog video produced by the Content Team (zulip).
docs.rs: building fewer targets by default
Changes to WebAssembly targets and handling undefined symbols
- Warning: this will introduce a small breaking change to WebAssembly targets
crates.io: Help test our new web frontend
- crates.io has its frontend rebuilt using Svelte 5. You can test it here: https://crates.io/svelte/
Infrastructure Team 2026 Q1 Recap and Q2 Plan

Stats

Total words of meeting minutes written: 551.3k (June 2025–April 2026)

Meetings attended: 45

Total words of meeting minutes written (April): 80.8k

Average (mean) word count per team meeting:

Cargo: 1.9k
Lang triage: 3.1k
Libs-API: 4.7k
Leadership Council: 2.4k

Program management update — March 2026

2026-04-09T00:00:00+00:00

Greetings and happy spring to you if you live in a place that's getting spring now!

Team meetings

After his onboarding, Nurzhan is able (and comfortable) to attend team meetings alone. That lets us split the load evenly while keeping the same PM coverage. We can cover for absences, but overall, our personal meeting strain has dropped by half.

This is great! As wonderful as it is to be in the room where things are being decided, help people out, and record the discussions for posterity, it is draining work — especially on days with 6–7 hours of back-to-back meetings.

We're still experimenting with the schedule, but we've made a conscious choice not to specialize. We both participate in each team's discussion and get to know people, and have them get to know us. That makes it easier to share our knowledge and context, as well as being able to step in when the other one can't make it.

We're both, of course, talking regularly, reading notes from the meetings we didn't attend, and if there's anything that needs to be tracked or handed over from one meeting to the next, we do that.

This frees us up to do more of all the other work!

On the topic of meetings, two changes happened. First, Josh Triplett proposed to temporarily pause the Style team meetings. For the last few months (and sporadically for much longer than that), only two Style team members were participating.

The team needs more members (as does rustfmt) and ideally a rustfmt liaison in the meeting. We are looking for options, but for the time being, urgent issues can be handled asynchronously.

The other bit of news is that the two Libs-API meetings have merged into one. We used to have one session for items (issues, PRs, etc.) nominated to the team, and a separate one to go through the open API Change Proposals (ACPs). These both happened on Tuesdays with an hour in between.

But the boundary between them wasn't particularly strong (if we cleared the nominated backlog, we started looking at ACPs in the first meeting), and the people generally wanted to just continue.

And now they can! The two meetings merged, which lets everyone keep going and finish an hour earlier as well. Or more if the discussion is particularly draining.

Program management board

We have now populated the Rust program management board so you can see what we're up to.

This lets us track and coordinate work better, as well as making it more transparent.

Project goals

The 2026 Project goals RFC is now open! This is the culmination of the work the Goals team has done in the last few months.

You can take a look, and if you have any questions, drop by the project-goals/2026-workshop channel.

And if you are a team lead, please review the RFC and either raise a concern or tick your box!

We're also getting to the end of the 2025 H2 goal period. We have one final update in the works (that we'd like to publish once the 2026 RFC is merged), and then it's full speed ahead for 2026.

A good number of the 2025 goals will continue into the 2026 period, and for these, not much will change. We'll reuse the tracking issues, Zulip channels, and everything else.

The new goals will have a tracking issue created. Any goal updates should go there, and they'll be automatically posted to the corresponding Zulip channel, where we can have a discussion.

Twice a month, we're also sending reminders to post an update (if there is a recent update already, the reminder will not be sent).

FLS Release Notes

The FLS is a specification of Rust for use in safety-critical environments such as cars, originally developed by Ferrous Systems. It was donated to the Rust Project and is now maintained by the FLS team.

As part of their Stabilize FLS releases goal, they plan to release a new version of the FLS six weeks after any given release of Rust is shipped.

Until now, they've been playing catch-up by waiting for a release and then going through the release notes, looking for any changes that need to be reflected in the document (specifically, language changes). They would like to begin earlier, but they need a list of issues getting into a given release before the notes are all typed up.

So Pete LeVasseur reached out to the Release team and agreed to try participating in the initial triage process for release issues. That way, they'll understand the process better, help out, and get the issue list they need early!

This is a good reminder that the process is completely public. More contributors are always welcome, and this can also serve as an accessible entry point into more general contribution.

Mirroring crates.io and Rust releases

Early in March, we opened the Implement Verifiable Mirroring Prototype project goal. This is a continuation of the previous signing explorations but with a narrower focus. The plan is to provide a mirror for Rust crates and releases to help with high-traffic environments such as GitHub Actions.

The prototype will let us verify the proposed approaches (such as using The Update Framework (TUF) to validate mirror updates) and key rotation while providing functionality that should help reduce bandwidth usage and cost (with GitHub Actions accessing mirrors hosted on Azure).

This functionality will be implemented behind unstable feature flags, but if it proves out, we can use it to build more general mirroring support.

Until the tracking issue for this goal is created, updates will be posted to the tbd-signing channel in Zulip.

Rust Foundation Maintainers fund (RFMF) RFC

In December 2025, we mentioned the maintainer fund and the formation of the RFMF Design Committee. They interviewed several open source organizations that have similar programs in place (Python Software Foundation, Scala Center, Django, and Zig Software Foundation) and proposed an RFC.

The RFC proposes creating a Maintainer in Residence role:

The Maintainer in Residence program is dedicated to hiring long-term maintainers and funding their maintenance work in full. Maintainers' in Residence time is split between priorities guided by the teams they are supporting and priorities of their own choosing within the Project.

These maintainers are expected to be Project members with good standing in the community, able to do long-term work keeping the Project healthy and evolving.

It also proposes forming a Funding team, which will select the candidates along with the Leadership Council and ensure the program's overall success.

This is complementary to the proposed Grants program, which provides financial support for twelve months for people already doing valuable work for the Project. They're not being hired or contracted, but we want to recognize their great work and make it easier for them to continue.

Outreachy internships

The Rust Project is participating in Outreachy! It is a paid open source internship program for people underrepresented in tech.

The Council has allocated money for three internship slots for the May–August 2026 internship round.

We have five projects proposed (adding Rust to an existing C/C++ build system, calling overloaded C++ functions from Rust, code coverage of the Rust compiler at scale, fuzzing the a-mir-formality type system implementation, and improving the security of our GitHub Actions). Right now, we are in the contribution period. This is where the applicants make contributions to the Project, and these contributions will help select the interns.

Personally, I (Tomáš) am extremely happy about this. I love what Outreachy does and stands for. I've known and worked with several people who have participated in the program, and they are all fantastic people and colleagues.

Huge thanks to Jack Huey for organizing it! And thanks to Niko, Rémy, tiif, teor, Joel Marcey, and Ethan Smith for signing up as mentors and co-mentors!

Rust for Linux

Boxy is leading const generics and wanted to know which areas would be most relevant to the Rust for Linux team. There's a lot of functionality under the const generics umbrella, and so it's important to know what to prioritize.

This is what the team brought up:

Ability to do arithmetic on const generic types: e.g., the kernel has a type Bounded that 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 arithmetic on these types (starting with bit shifts), which will guarantee that the result fits within the specified size at compile time.
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: { ... }.
Being generic over types other than numbers: pointers would be useful for asm_const_ptr. String literals would be useful, too — even if they're just passed through without being processed or 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.

In other updates, Gary added an infrastructure to provide pointer projection via a macro.

The dma_read!/dma_write! macros switched over to it. Note that 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.

On that note, the lang team held a design meeting to discuss Field Projections via Virtual Places, the latest proposal from Benno Lossin, Nadrieril, and Tyler Mandry. You can read the proposal and meeting notes here.

Finally, as a follow-up on the rustfmt use discussion, Tomáš opened an issue for keeping imports on individual lines the way Rust for Linux needs without having to use the trailing // workaround.

Rust for CPython

We had one meeting with the CPython folks in March.

Drop with context

Python objects are reference-counted pointers. At any given time, they're either attached to the Python interpreter or not. When attached, their reference count can increase or decrease, but they must be detached to make any native calls. These pointers can't be Clone or Drop, because the trait implementations don't know whether they're attached to the interpreter state.

There's an open question on how to model this in Rust so that it's both safe and ergonomic.

David Hewitt asked about the "Drop with context" feature, which would require that an associated context (e.g., a pointer to the Python interpreter state) is implicitly passed along to the drop function.

This is something the Project has been thinking about (see Tyler Mandry's 2021 post, the recent What If Traits Carried Values post by Nadrieril, and the related 2026 Dictionary-passing style goal proposal). David, Josh Triplett, and Jack Huey plan to keep discussing this on Zulip as well as at the 2026 All Hands.

Sanitizers

CPython runs sanitizers (AddressSanitizer or ASan, MemorySanitizer or MemSan, UndefinedBehaviorSanitizer or UBSan, and ThreadSanitizer or TSan) in CI to provide additional checks of the C code. These are important for Python's memory safety.

Emma Smith wanted to confirm whether LLVM and GCC-based sanitizers can be mixed — and they can't. When using Rust, the C portions of the Python interpreter will have to be built using Clang, and those will need to use its own sanitizers. And we need to make sure that these cover the same ground.

The team also asked about compatibility between LLVM releases given that Rust uses its own LLVM fork. The answer is that while the major versions of LLVM are incompatible, Rust's fork and the corresponding upstream version should be compatible. Rust carries backported upstream bugfixes and supports building with stock LLVM.

There is also ongoing work to stabilize MemorySanitizer and ThreadSanitizer driven by Rust for Linux.

Future meetings

We haven't had any new topics after the beginning of the month, and so we put the meetings on hold for now. When new topics come up, we will talk again, but at this point, there's just a lot of work to be done. The Rust and CPython folks do plan to hold a joint session at the 2026 All Hands.

In the meantime, Emma Smith posted a progress update from their perspective. The team has finished the build system work, and it's passing the CPython CI. In the coming months, they'll plan the internal Rust API design, and after that, write the PEP (Python Enhancement Proposal — similar to our RFCs) targeting Python 3.16.

Worth a look

Rust Foundation posts

Canonical Joins the Rust Foundation as a Gold Member
What’s Next for the Rust Innovation Lab?

Rust Project updates

Announcing Rust 1.94.0 and 1.94.1
Security advisory for Cargo
Changes to WebAssembly targets and handling undefined symbols
- Heads-up for a breaking change for WebAssembly builds
docs.rs: building fewer targets by default
- Heads-up for a breaking change docs.rs will make on 2026-05-01
What we heard about Rust's challenges
Announcing rustup 1.29.0
2025 State of Rust Survey Results
Call for Testing: Build Dir Layout v2
- Since Cargo 1.91 it's possible to separate the location of intermediate build artifacts (build-dir) and final artifacts (target-dir) into separate directories.
- Now, Cargo is changing the layout of build-dir. The target directory's layout is unchanged.
- They're asking to test this to help uncover things such as build scripts using it to infer target_dir or executable path.
- Please consider testing this and reporting any issues you encounter.
January & February 2026 Project Director Update
Leadership Council update — March 2026
- Rémy Rakic joined as the compiler team representative
- Josh Triplett joined as the libs team representative

Stats

Total words of meeting minutes written: 470.5k (June 2025–March 2026)

Meetings attended: 35

Total words of meeting minutes written (March): 73.8k

Average (mean) word count per team meeting:

Cargo: 1.9k
Lang triage: 3.3k
Libs-API: 4.3k
Leadership Council: 2.4k

Leadership Council update — March 2026

2026-04-06T00:00:00+00:00

Hello again from the Rust Leadership Council! We wanted to share an update on what the Council has been working on since our last update.

Accomplishments so far

Welcome Rémy Rakic and Josh Triplett to the Council

The March representative selections have completed. There were several changes made to the Council:

Mara Bos stepped down as the libs team representative to switch to be the launching pad representative.
Josh Triplett has joined to take Mara's place as the libs team representative.
Rémy Rakic has joined as the compiler team representative.
Eric Huss remains as the dev tools team representative.

We'd like to thank our outgoing representatives James Munns and Josh Stone for their time on the Council. We've greatly appreciated their support!

Thanks to everyone who participated in the process! The next representative selections will be in September 2026 for the other half of the Council.

Welcome Nurzhan Saken as our second Program Manager

In February we welcomed Nurzhan Saken as our second Program Manager joining Tomáš Šedovič. This will help make our PM program more sustainable and strengthen the support it provides. You can read more about Nurzhan in the recent PM update.

Project priorities budget

Since 2024, the Project has managed a Project Priorities budget. The council spends funds from this budget on activities that support the work of the Project. At the start of 2026, the Foundation allocated to this budget $306k (USD) in new funds and transferred $106k in remaining funds from the Project Grants program. For the past several months the Council has been working on allocating towards various priorities. The following items have been approved:

Raised our travel grant limit to $100k (#254). Note that in addition to this, the Foundation is providing an additional $50k for RustConf travel.
Allocated an additional $160k for the Program Manager program, which combined with the remaining budget from 2025 gave us about $344k starting balance for the year. (#255)
Allocated $25k for Outreachy mentorship (#264).
Allocated $55k for the compiler-ops contract (#244).

In addition to these already allocated funds, we are discussing whether to reserve the remaining amount with the following:

Funding the Content Team with $15k to help produce video content (#279).
Restarting the grants program with $100k to support existing maintainers (RFC#3919).
Considering an unspecified amount for web design support on crates.io (#278).

Additional items

Finalized an alumni policy that involves an annual notification to members to let them know which teams they are a member of, and to check if they are still active. #218
Updated the responsibilities of Project Directors to better define and clarify expectations. #250
Clarified that the mentor team doesn't need to ask the Council to participate in GSoC 2026. #253
The Foundation has updated the process for travel grant applications. #259
Approved a proposal for delegating guest invites for the All-Hands. #252

Ongoing work

Rust Foundation Maintainers Fund

In December we formed a committee (#248) to put together a proposal to define how to use the funds from the Rust Foundation Maintainer Fund. The RFMF is a dedicated fund used to support Rust Project maintainers.

The team has been working very hard on a proposal which is now open for comments at RFC#3931.

Contribution policy

A lively discussion has been taking place around policies for AI contributions, prompted by an increase of "slop" submissions to the project. An interim proposal was submitted in #273, which was intended to address some of the immediate concerns in the rust-lang/rust repository. A second proposal was also submitted that focuses on the desired kinds of contributions and that has since moved to RFC#3936 to gather comments from the project. This is an important question for the Project, and we expect this to continue to be a focus in the near term as we continue discussions and consider different proposals.

Additional items

James Munns has continued to work on the Rust Society proposal by collecting a group of interested parties to help administer the program. #260

Following our work

To follow our work in real time, watch our repository. You can also see meeting summaries posted on Zulip in #council > Meeting minutes & summaries.

Meeting minutes

We publish minutes from all Council meetings to the Leadership Council repo. Links to the minutes since our last update are:

December 5, 2025
December 19, 2025
January 16, 2026
January 30, 2026
February 13, 2026
February 27, 2026
March 13, 2026
March 27, 2026

Program management update — February 2026

2026-03-27T00:00:00+00:00

Greetings! This update is brought to you by Tomáš Šedovič and Nurzhan Saken \o/.

Hello from Nurzhan

I discovered the Rust Project in 2022 and quickly became obsessed. The language, the documentation, tracking issues, changelogs, blogs, talks, and user/contributor discussions — all of these scratched an itch and comforted me during a difficult period in my life. As a huge introvert, I mostly observed and didn't participate, so the job posting for a program manager felt like a wake-up call. Tomáš put it well in his first update: I had to apply despite many doubts about whether I would actually do a good job; the regret of not going for it would have been devastating.

TC and Joel Marcey interviewed me in March–April 2025 and considered hiring me. This was a surprise because I felt like a total mess! Alas, you may know from the previous update that things didn't go as planned, and I didn't end up getting the position. Still, there was no going back, so I started engaging with Rust by stabilizing multiple features I was interested in. Eventually, more funds did get allocated, and I was hired.

The first month felt surreal. Suddenly, the imaginary barrier vanished, and I found myself sharing spaces (and even interacting) with the people whose work I had admired so much. Tomáš had been leaving behind some impressive footprints, seemingly impossible to match. It was easy to feel like there'd been some mistake, that I didn't belong. Yet, everyone has been so welcoming. Tomáš has been going out of his way to talk to me, support me, and loop me into everything happening in the Project. Thanks to that, I already feel mostly integrated, well-equipped, and really lucky that things have turned out this way.

Project goals

February was focused on getting through the proposed goals and having teams look at them. We are currently at 0 open pull requests (with huge help from Nurzhan), and we incorporated the sizing and champion feedback from the teams looking at the goals.

Each goal typically has one or more asks for Project teams (e.g., Lang, Compiler, Libs), so it is important that they review all their asks, see whether they're clearly articulated, and determine whether the proposed changes make sense in the Project.

In March, we'll do a final pass over the individual goals to make sure they have the right champions and sizes. After that, we'll open an RFC listing all the proposed goals and get feedback from the teams.

That is an important time because, until now, goals were considered mostly in isolation. But with the RFC, we'll be looking at the full picture as teams consider their overall capacity for the full year.

We aim to have the RFC reviewed in March and officially start the new goal period at the beginning of April.

We also discussed the way we do Project goal updates. The current auto-generated blog posts leave a lot to be desired, and we're interested in your feedback!

If you've read them previously, and especially if you haven't, we'd love to hear from you! What's helpful? What isn't? What would you like to see vs. what might be distracting?

We're talking to the Content team about ways to highlight specific goals in individual posts or interviews. We're also looking at making the updates more meaningful. Hearing your perspective here would be valuable! You can tell us on the Blog post thread on Zulip or DM the T-program alias.

Here are the recent blog posts we've published:

December 2025
November 2025
October 2025

Program management tracking

Given that there are now two people taking on the program management work full time, we created places dedicated to that.

First, we have a backlog/board where we will track our work. Any issue from any rust-lang repo can be added there.

Since some topics won't fit into any of the existing repositories (things like scheduling the signing & mirroring meetings or writing the monthly PM update come to mind), we also had the program-team repository created. It can also house any documentation and tooling related to the effort.

Finally, you can now use the T-program alias on Zulip to talk to us, tag us on a thread, or make a request.

We're hoping this will make it clearer how to reach out to Program management, provide greater transparency (to show what we're actually working on), and, of course, help us (the PMs) coordinate better.

As of this writing, the repo and board are both empty. There are a few issues in other repos that we can link there, but mainly, Tomáš needs to move the contents of his Rust org-mode file over.

C++/Rust interoperability

The Foundation hired teor for a short-term contract to speed up the mapping of the interop problem space, and they hit the ground running.

teor read through all the existing documents that we had, created a template for each issue / problem statement (e.g., exceptions & unwinding or incompatible allocators), immediately started documenting the known ones and filing issues for the various use cases that projects integrating these two languages have.

They're posting weekly updates on Zulip and monthly ones in the Project goal tracking issue.

These updates and the focus on mapping out the technical aspects are a result of feedback provided to the Foundation by the Project members and the wider community (directly, as well as indirectly, e.g., through Project Directors and Program managers).

If this is an area you're interested in, please take a look at the interop-initiative and the t-lang/interop Zulip channel.

Signing and mirroring

Following up from January, Walter Pearce proposed a draft of the Project goal. It focuses on building an MVP that sets up a mirror for Rustup targets. This would happen fully on the backend (and should therefore be completely transparent to any users) to look at bandwidth and logging cost reduction, stand up the security infrastructure, and get hands-on information to build the ultimate solution.

We've added a few more people to the group (e.g., Rustup folks), and the draft is under active discussion. There are still questions to resolve both on the technical and communication sides, but the proposal seems to be in a solid place, and we hope to have a PR open soon.

Style

For the last several months, a lot of the meetings ended up canceled. At the end of January, I scheduled a new time with a fortnightly cadence, and we've met two times since.

In the first one, we triaged all the nominated issues. Recognizing the capacity issues (the Style team has three members, and lately, one of them has not been able to dedicate a lot of time), TC proposed we focus on getting things unblocked while leaning on others.

So, when an issue comes in, the Style team considers it, figures out where it fits within the existing guidelines, and then asks the submitter for a concrete proposal instead of writing it all down themselves.

This practice is similar to how the Lang team operates.

The last two meetings felt much more productive that way, but the capacity issue remains. We need help!

If you're interested in how the language is formatted — providing input on what rustfmt should do — we would love to have you! You can join the t-style channel or attend one of our meetings.

Rust for Linux

We discussed the Rust for Linux roadmap and went over all the other unstable features the project is tracking that are not part of a particular goal. These are to be tracked in the roadmap, and we'll be spinning up goals where that makes sense.

There is an important milestone of sorts for Rust for Linux: the upcoming Debian 14 Stable release (codename: Forky). The version of the Rust toolchain provided by Debian Stable releases is what Rust for Linux currently uses to decide which minimum version to support. For instance, assuming Debian Forky releases around Summer 2027 with, say, Rust 1.104.0, then Rust for Linux will be able to use the new (and possibly unstable) features available in that version when the kernel's MSRV is bumped some time after Debian's release.

Rust for Linux supports a range of stable toolchains, each having access to a subset of unstable features (some of which the project depends on). This creates compatibility issues whenever the same functionality appears in different forms across the supported toolchains. For example, a feature may be unavailable in the oldest version, unstable in a newer one, and stable in a later one. Some of these issues can be handled at build time (e.g., when a flag is changed from -Z... to -C...), but others require non-local conditional compilation (which means maintaining parallel codepaths). The former tends to be easier to deal with without an MSRV bump, but the latter is much harder, and raising the MSRV in those cases has the potential to eliminate a substantial compatibility burden. To avoid particularly heavy maintenance costs, the team may choose to wait for the next MSRV before adopting a new feature at all.

With that in mind, we looked at features with the most significant impact that Rust for Linux wants to start using as soon as the next MSRV upgrade becomes possible. Some of the most notable ones are:

Arbitrary self types
Field projections
Immovable types and guaranteed destructors
ADT const params
rustdoc --output-format=doctest
Relaxing Rust's orphan rules — later this year, the team wants to split the monolithic kernel crate into sub-crates, at which point they will need to deal with the orphan rules. One approach is to relax the orphan rules within a set of crates (a coherence domain). This idea was informally proposed in 2022 and recently revisited. We hope to formalize this approach (or consider another) through continued discussions.

In general, Rust for Linux wants to start using new language capabilities (especially those with new syntax) as soon as the MSRV allows, since supporting both old and new forms across the toolchains can become burdensome, and delaying adoption may also lead to large-scale refactoring later. If the new syntax can be hidden behind a macro, that is usually acceptable. Likewise, using an unstable feature is acceptable so long as there's a reasonable expectation that it will be stabilized in roughly that form or at least won't be removed. For example, immovable types could supersede Pin, leading to massive syntactic changes. A special case is in-place initialization: the team has a working solution for the underlying problem, with a potential path to integrate with the eventual language feature, so its absence is less blocking than field projections, which doesn't exist in any form yet.

Rust for CPython

At the beginning of February, we invited Miguel Ojeda (the Rust for Linux lead) to share insights from his team's experience introducing Rust into the Linux kernel.

Miguel went over the rough timeline of Rust for Linux: the effort gained traction in late 2020, leading to an RFC in early 2021. Minimal experimental support was merged into mainline in late 2022, and the experiment concluded in late 2025. Collaboration with the Rust Project began around 2021 and transitioned to regular meetings in early 2024.

When the project started, there was skepticism around introducing Rust into a mature C codebase. C had long been the main language used in the kernel, and there had been resistance to adopting additional languages (e.g., C++ was briefly experimented with in 1993 before being abandoned). There were concerns about the downsides of moving to a two-language codebase and the need for developers to learn a new language and toolchain with benefits that were not yet clear.

The team spent a lot of time discussing these concerns with maintainers and contributors on mailing lists and at conferences, as well as following public discussions and the news to understand how they could communicate better. In 2025, Miguel presented a keynote showcasing what kernel maintainers, team members, stakeholders, and companies had thought about Rust for Linux at that year's FOSDEM event.

In the RFC Miguel proposed, they were honest about the advantages and disadvantages of Rust. A lot of the kernel experts thought that memory safety was the main appeal, but the RFC highlighted benefits beyond that: a clear separation between safe and unsafe code (with the former having no undefined behavior, memory safety violations, or data races), useful language features (rich enums, pattern matching, modules, hygienic macros), and powerful integrated tooling (rustfmt, rustdoc, lints). The RFC presented a port to Rust of the Android Binder IPC mechanism as its initial use case, and the resulting feedback led to the first hardware drivers being written in Rust (such as a translation of a GPIO one with a line-by-line comparison with the C implementation).

The team prioritized raising the bar on the quality of Rust code and documentation, e.g., requiring SAFETY comments around each unsafe block, consistent code formatting, and fully documenting all public APIs. Over time, the Rust experience also benefited the C side. For example, reviewing C code to design Rust abstractions sometimes uncovered issues that had gone unnoticed. More generally, the team has observed Rust concepts starting to percolate into the C side in discussions and designs; a recent example is the discussion around Revocable for C.

All of this strongly resonated with the CPython developers, who saw very similar reactions to their proposal and are facing similar technical challenges. Emma Smith, who leads this effort along with Kirill Podoprigora, mentioned that the Rust for Linux proposal was a huge inspiration for them to start this effort for CPython.

The Rust Project is happy to see cross-pollination in this space, and we'd love to see (and help!) more projects adding Rust to existing code.

Other than that, we kept talking about build systems and linking. Compared to when we started, we got through a lot of the immediately pressing topics. So now we're only meeting when there's enough to talk about. That currently works out to about every two weeks.

Worth a look

Rust Foundation posts

FOSDEM 2026 — Rust Devroom in Review

Rust Project updates

Writing a Linux GPU Kernel Driver in Rust with Daniel Almeida
- Interview from Kangrejos 2025
Announcing Rust 1.94.0
2025 State of Rust Survey Results
Rust participates in Google Summer of Code 2026

Stats

Total words of meeting minutes written: 396.7k (June 2025–February 2026)

Meetings attended: 45

Total words of meeting minutes written (February): 73.7k

Average (mean) word count per team meeting:

Cargo: 1.6k
Lang triage: 2.5k
Libs-API: 4.8k
Leadership Council: 2.4k

Posts tagged "program" | Rust Blog

Leadership Council update — September 2026

Accomplishments so far

Welcome Mark Rousskov and Pete LeVasseur to the Council

Project Director Elections

Rust Foundation Maintainers Fund

Project priorities budget

LLM policy discussions

Additional items

A word of thanks

Following our work

Meeting minutes

Program management in July–August 2026

Project Goals

Infrastructure

Team building

Content

Rust for Linux

The core of core?

Integer casts

Newtype literal constructors

Project updates

All Hands 2026 retrospective

Sessions

Feedback

All Hands 2027

Program management update — June 2026

Meetings

Project goals

Funding

Help wanted

New goals

Leadership Council

T-comprehensibility

The next All Hands

LLM committee

Program management

Rust for Linux

Rust for CPython

Worth a look

Project updates

Foundation posts

Stats

Program management update — May 2026

RustWeek and All Hands!

Interviews

Program management

Funding Rust maintainers

Mirroring

Rust for Linux

All Hands session

Recoverable integer overflow

Tomáš's July/August absence

Worth a look

Rust Project updates

Rust Foundation posts

Stats

Project goals update — April 2026 (end of 2025H2)

Table of contents

Flagship: Beyond the &

Plan for 2026

Blockers

Help wanted

Flagship: Flexible, fast(er) compilation

Flagship: Higher-level Rust

Blockers

Blockers

Blockers

Flagship: Unblocking dormant traits

Other goal updates

Blockers

Help wanted

Blockers

Blockers

Help wanted

autodiff

offload

autodiff

offload

#![register_tool] rust#66079

The core of `core`?

Flagship: Beyond the `&`

`#![register_tool]` rust#66079

`-Zdebuginfo-compression` rust#120953

`-Zdirect-access-external-data` rust#127488

`--emit=noreturn`

`--emit=noreturn`

`Deref` / `Receiver`

`derive(CoercePointee)` rust#123430

Removing the `likely`/`unlikely` hints in favour of `cold_path`

`statx`

`Deref`/`Receiver`

`cargo report` commands

`cargo report sessions`

`cargo report rebuilds`