Inside Rust Blog

Program management update — May 2026

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

Program management update — May 2026

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

How Josh helps Rust manage code across multiple repositories

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

The Rust Project develops and maintains several developer tools, such as Cargo, Clippy, rustfmt, Rust Analyzer and Miri. These tools are developed in separate git repositories, which enables customizing their issue and pull request (PR) management, Continuous Integration (CI) workflows and development processes based on the needs of the specific teams that maintain them. However, these tools also need to be somehow integrated within the main rust-lang/rust repository, primarily for the following two reasons:

The CI of this central repo is responsible for distributing the Rustup components containing these tools, which we then ship to Rust programmers.
When we make a breaking change to the (unstable) internal compiler API, on which some of these tools depend, we sometimes need to fix them in the same pull request, to ensure that they keep working on the nightly toolchain.

This means that we have to deal with the classical problem of managing development of code across several repositories that depend on one another. This post covers our experience and some problems that we encountered with this cross-repository code sharing and describes how we leverage an awesome git tool called Josh (Just One Single History), which helps us overcome these challenges.

Problem statement

First, let us define more concretely what is the problem that we are trying to solve. We have one "parent" repository (in our case rust-lang/rust), which has a set of dependencies, which we will call "subprojects" (e.g. rust-lang/miri or rust-lang/rust-analyzer). The parent and the subprojects are developed independently. The parent must have access to a specific snapshot of the subproject's source code. Periodically, the subproject's code in the parent repo should be updated to a newer version. And ideally, the parent should be able to atomically change both its and the subproject's source code.

There are several traditional ways of attempting to solve this issue, which did not fully work for us for various reasons.

Monorepo

If both the parent and the subprojects all live inside the same repository (a "monorepo"), then the desired properties described above are trivially satisfied. The parent always sees the latest version of each subproject, and it is possible to atomically change both the parent and the subproject inside a single pull request. While this approach has many benefits, and rust-lang/rust is conceptually a monorepo (it contains the source code of the compiler, the standard library, rustdoc and many other things), it also causes some friction. The compiler repo is quite large, which can be scary for new contributors, and it has quite slow and complex CI. Its development processes are also mostly tuned to the Compiler team's needs, but our developer tools are maintained by other teams that use different review or issue tracking practices.

Keeping some subprojects (such as Miri or Rust Analyzer) in their own repositories thus makes their CI faster, enables them to be deployed separately from the main Rust toolchain, and simplifies onboarding of new maintainers, who can more easily obtain scoped permissions to merge PRs only for the given subproject, and not "all of Rust".

git submodules

Perhaps the most straightforward way of including a git repository in another one is to use git submodules. We currently use submodules for some dependencies, such as Cargo and LLVM. Their benefit is that they are easy to set up, you simply point a directory to a specific commit SHA of an external repository, and that's it. Unfortunately, that is where most of its advantages end.

In practice, submodules can be quite annoying to work with. Developers have to properly checkout the submodules using e.g. git clone --recursive or git submodule update, otherwise they can remain empty or contain the wrong commit. It is in fact a relatively common mistake for someone to accidentally commit and push an unrelated submodule change to their pull request branch, because git sometimes keeps submodules in a "dirty" state when switching branches. We had to build custom logic to checkout specific submodules to the correct commit when building a given Rust artifact in our build tooling (bootstrap) to alleviate this, but it is not perfect.

Another big disadvantage of submodules is that they do not allow atomically modifying the subproject and the parent in a single PR, because the submodule is fundamentally only a link to a repository. When we make (an internal) breaking change in rust-lang/rust, we would thus have to:

Merge the rust-lang/rust PR with the breaking change
Update the subproject in a separate subproject PR
Merge another rust-lang/rust PR which updates its submodule to point to the new subproject commit created in step 2.

This is a lot of additional busywork, which makes it harder to land changes that affect both the parent and the subproject. Sometimes it is near impossible to make such a change without at least temporarily breaking the CI of one of those two repositories, or producing a nightly release where the tool would stop working. We used such a system for Clippy, Miri and a few other tools in the past, and both the user and developer experience was extremely poor.

git subtrees

Since submodules are not a great fit for tools that are deeply integrated with the compiler (such as Miri or Rust Analyzer), we historically used git subtrees for them instead. A git subtree essentially integrates the whole repo of the subproject into the parent, which then directly contains all of its source code and its whole git history, rather than just a link (as with submodules). It is thus possible to change both the parent and the subproject's code in a single pull request, to e.g. fix the subproject tests after something changes in the compiler, which is very useful.

The price that has to be paid to enable this workflow is that we need to periodically perform bidirectional syncs between the parent and each subproject that is embedded as a subtree. There are two kinds of syncs:

A pull operation ports any changes made to the subproject in the parent repo back into the repository of the subproject.
A push operation updates the subproject's source code in the parent based on the latest commit of the subproject repository.

Performing a sync means that someone has to run a script to do a pull or a push, resolve any merge conflicts or test failures that may arise, and submit a PR to the corresponding repository.

This workflow conceptually worked pretty well for us, but we had a severe problem with the implementation of git subtree: it is painfully slow. The official upstream version is entirely unusable for a repo of our size. There exists a patch that was never merged upstream that made git subtree fast enough for Clippy and a few other tools. However, on Miri, likely due to its complex history that involves moving a large chunk of code from Miri to rustc in a history-preserving way many years ago, git subtree became entirely unusable: even after many hours of waiting, the sync would simply not finish.

Apart from performance, we also encountered some other issues with subtrees, such as git blame not working properly or commits being duplicated when the subproject is changed in the parent repository.

git subtree has served us well for many years, but we have outgrown what it can handle. Luckily, we found an alternative that is much faster and avoids the other problems.

Josh comes to the rescue

Josh is a tool written in Rust that implements sophisticated and performant filtering operations on git repositories. It provides a set of reversible git algebraic filters that allow manipulating the history of git repos, which enables several cool use-cases. For example, it offers a git proxy that can transparently split a repository into a set of subrepositories on demand, rearrange, exclude or extract the git history of specific directories or linearize the history of a repository that uses merge commits. We mostly simply use it as a very fast "git subtree on steroids". In fact, our Josh workflow is very similar to the way we use git subtrees, with the biggest difference being that the sync operations are an order of magnitude faster and the resulting history is (mostly) cleaner.

To make our subproject handling even easier, we built a small Rust tool on top of Josh, called josh-sync. This tool provides a lightweight interface on top of the powerful Josh engine, which allows us to unify the way we handle pulls and pushes across all our subprojects that use Josh. We even prepared a reusable GitHub Actions workflow that is used in several subproject repositories to periodically perform the pull operation, open a PR directly from CI, and let us know on Zulip if the sync cannot be performed without manual intervention.

We currently use Josh to handle subtree synchronization for Miri, Rust Analyzer, compiler-builtins, stdarch and the Rust Compiler Development Guide. While there are still a few subprojects that use git subtrees (e.g. Clippy), our plan is to eventually migrate all these remaining subprojects from git subtree to Josh, and improve our tooling to make the bidirectional sync even easier and faster for the maintainers of our developer tools.

We started using Josh a few years ago, and we are very happy that something like it exists; otherwise we would probably have to build it ourselves to deal with the scale of our repositories. Thankfully, Josh's maintainers, especially Christian Schilling, are very cooperative, and they are continuously improving Josh to meet our (sometimes quite challenging) needs.

For instance, the main downside of Josh that we ran into is that a "pull" sync creates a huge amount of merge commits in the subproject. In response to that, the Josh developers improved the logic for avoiding trivial merges, and they are currently helping us with the non-trivial migration to these better filters. Conversely, over the years, our use-cases helped uncover several edge-cases in Josh, and they often serve as a stress test for its performance.

So, with that being said, we would like to thank the Josh maintainers for enabling us to scale our complex development workflows! If scaling git repos and workflows sounds interesting to you, then check out Josh to see if it might also help your versioning use-cases.

Maintainer spotlight: Tiffany Pek Yuan (@tiif)

2026-06-03T00:00:00+00:00

There are hundreds of people who maintain the Rust toolchain, often on a volunteer basis on top of another job. The Rust Content team is working on a series of blog posts highlighting some of these prolific contributors to recognize the awesome work that they are doing in order to make Rust better for everyone. This post is the first one in the series.

In this post, we would like to introduce Tiffany Pek Yuan (@tiif). Tiffany started contributing to Rust only two years ago, as a Google Summer of Code (GSoC) contributor. Since then, she already became a member of the Compiler and Formality teams, and made substantial contributions to several projects, including the compiler, Miri and a-mir-formality. She also transitioned from being a mentee to a mentor, as she now mentors another contributor in the Outreachy program.

Currently, she is finishing her college degree while also working on the Rust compiler as a Rust maintainer intern in the RustNL Maintainers Team.

I got to know Tiffany as a GSoC student adding miri support for checking unsafe code in tokio. It was a joy to mentor her, and subsequently seeing her sticking around and learning about formality and rustc on her own.

Oli Scherer, Rust compiler team member and Tiffany's GSoC mentor

We interviewed Tiffany to find out about her experiences with joining the Rust Project and contributing to Rust. Read more below!

Can you briefly introduce yourself?

Hi, my name is Tiffany Pek. I'm currently studying a Bachelor's degree in computer science at the National University of Singapore. I should hopefully graduate in a few months! I contributed to various parts of Rust, right now I am focusing on a new trait solver bug fix that is related to implied bounds and modeling the borrow checker's semantics in the a-mir-formality project, which attempts to define a model of the type system.

How did you start with Rust? Did you learn it in one of your classes, or was it a hobby?

I did eventually attend a subject on Rust, but I already learnt it before that by myself. I heard about Rust around 2022, because I was searching for a systems programming language. I tried it for a research project and I really liked it. I tried a lot of programming languages before that, such as Java, Python or C++. They weren't bad, but Rust seemed much more enjoyable. What fascinated me about it were its really nice error messages.

How did you get involved with the Rust Project?

I remember telling my friend in college that it would be so cool to contribute to the Rust Project. Then, just a month later, I learned about Rust's involvement in Google Summer of Code (GSoC), and I immediately thought "I must join this program"! We all knew about GSoC at our university, but not many people tried to apply to it for some reason. I applied to GSoC and got accepted.

I think I would eventually contribute to Rust even without GSoC, but this internship gave me an opportunity to work on Rust almost full-time, without having to care about getting another job. That was very helpful.

How was your experience with GSoC?

I think it went really well! The experience was really enjoyable, because there were several other interns working on other projects at the same time. And all of us were kind of "newbies", so I wasn't the only person struggling with something. For example, when I messed up rebasing one of my pull requests, I saw that the same thing happened to another GSoC contributor, so I was like "oh yeah, we are the same!" and I didn't feel so bad about it. Also, Oli is a very nice mentor too, I had a lot of fun talking with them.

Jakub is also a really good organizer, which makes the program a huge success. I was really impressed by how we already discussed burnout even before the internship started.

Overall, it was a great onboarding experience, and it motivated me to stay as I really love the community.

What was your GSoC project about?

I worked on Miri, which is the undefined behavior detection tool for Rust. At that time, it wasn't really possible to run Miri on non-trivial asynchronous Rust programs that used the tokio crate. I added support for various non-blocking I/O syscalls (such as epoll) to it, in order to expand the set of programs that Miri can handle. We then worked with Tokio maintainers to run Miri on most Tokio tests in their CI, which was quite exciting.

What was your first contribution?

I added two tests to Miri. While doing so, I found out that the contribution documentation contained some unclear instructions, so I also improved it in the same PR.

Would you recommend that approach for new contributors?

Yes, I think that improving documentation is a good way to start contributing to Rust. It is also important to first locate areas that you are interested in, because the Rust Project is huge, there is Miri, the compiler, rustfmt, rustdoc, rust-analyzer, Cargo, and many other areas in need of contributions. Before making larger changes, it is always good to discuss them first with the corresponding maintainers before you open a PR.

If you are just starting with Rust, always read the error messages, because they are really nice. And if you find the error message difficult to understand, it might be a bug, so go open an issue!

What made you stay with Rust even after GSoC?

I stick around because of the community. During GSoC, I started talking to other Rust GSoC contributors. I ended up meeting two of them and other Rust Project members at a conference in Beijing. Subsequently, I made many amazing friends at the Rust All Hands, which makes Rust no longer a purely technical project, but also a hobby project me and a lot of my friends love and care about.

How did you join the Compiler team?

I started contributing to Rust in March 2024. I worked mostly on Miri during my GSoC project, but later I transitioned to working on the compiler. I was invited to join the Compiler team in November 2025. I didn't expect the invitation at all, so it surprised me.

At that point, I already interacted with the Rust community a lot, so it didn't feel like a large change to join the team, but getting officially recognized does feel really nice. I also think that being a Rust team member might help me with searching for a job.

Are you happy that you joined the Rust Project?

I am very happy about it! The people in the Project are really nice, and we frequently talk with one another, which is great.

I was able to attend the RustWeek conference and the Rust All Hands in 2025 and 2026, which was super nice. I'm grateful for the travel grant that I got from the Rust Project and Foundation, which allowed me to travel to these events. I made so many friends there, which is part of the reason why I am still staying with the Rust Project. All my Rust friends were there!

What excites you about working on the Rust compiler?

I find the compiler really exciting! It is like a mysterious black-box. If you do not know about how it works, it can seem scary, but once you start learning about it, it is actually quite neat to work with.

I find the new trait solver and Polonius work (the new borrow checking implementation) very exciting because they are the very core part of the language. Once the new trait solver is completed, we will be able to unblock a lot of features and fix many unsoundness bugs. And Polonius will allow the compiler to accept many correct programs that were previously rejected, which can make the language even more expressive.

What is it like to work in the compiler team, which is large and very visible?

The compiler team is so big¹ simply because the codebase is very large, so everyone specializes in different parts of the compiler. I mostly only review parts of the compiler that I am familiar with. I never know what is going on in another part of the compiler, as there are just so many things happening every day.

Who is your biggest mentor in the Project?

It is multiple people, not just a single one. Initially it was definitely oli, because he was my GSoC mentor, and we talked (and still talk) quite a lot. Later I started working on type system stuff, where I help lcnr with the new trait solver. I also talk a lot with Boxy, who is now a co-lead of the compiler team.

Did you also try mentoring someone?

I try to leave easy improvements to other people, by opening issues for them that contain contribution instructions, and then try to answer questions from potential contributors on those issues. Recently I also started mentoring a contributor in the Outreachy program, which is exciting.

Would you like to change something in the Rust Project?

I know a lot of people who could produce awesome stuff if they had the opportunity to work on Rust full-time. But without funding, they have to work on and off, which is not very productive for them, and also bad for knowledge transfer. I wish more Rust contributors were funded.

Were you able to find funding for your own Rust contributions?

When I started contributing to Rust, I was funded by the GSoC program, which was nice. Later I joined an internship program at ETH Zurich, which also provided a source of funding. During those times, I was quite productive. But similar funding sources are usually only temporary. I am still a student, so I have to deal with my academic life, and I also need an extra job to support myself, which can be a bit difficult.

Finding a remote job can be tricky, because I live in Singapore, and the time zone difference is not that great. If I'm going to schedule a meeting with someone in the US, I usually have to do it at night. Luckily I don't go to sleep that early :-) But it can be an issue when interacting with people and companies from Europe or the US.

I hope to finish my studies soon, and after that I will have to get a full-time job. I think that I would still want to contribute to Rust even in that scenario, but I'm not sure yet how to do that. Maybe I would need to sacrifice my weekends a little bit, or something like that. It can be a bit difficult, but it is not impossible.

Right now, I have an internship in the RustNL Maintainers Team. It will be awesome if I can find a full-time job which allows me to work on Rust as I really love what I am doing now.

I think the upcoming funding efforts, such as the RustNL Maintainers Team and the Rust Foundation Maintainers Fund, will be able to financially support more Rust Project contributors. Though I am slightly worried about the incentives of companies funding maintenance work. Company interests are not always necessarily the same as the community's interests, which can create a bit of a conflict of interest. But I'm sure that there are ways to mitigate this.

We thank Tiffany for sharing her thoughts with us, and for all her work on improving Rust!

Currently, it has over 70 members. ↩

1.96.0 pre-release testing

2026-05-26T00:00:00+00:00

The 1.96.0 pre-release is ready for testing. The release is scheduled for May 28. Release notes can be found here.

You can try it out locally by running:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

The index is https://dev-static.rust-lang.org/dist/2026-05-26/index.html.

You can leave feedback on the internals thread.

The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.

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

March 2026 Project Director Update

2026-05-04T00:00:00+00:00

This post covers the Rust Foundation board meeting that happened on March 10, 2026. Read the full March minutes on the Foundation's site. Highlights include:

Sid Askary of Futurewei joined to discuss a proposal to create an AI-focused research initiative within the Rust Foundation. He shared an early draft and took questions from the board. The board will revisit the proposal in future meetings as it develops.
The Symposium project applied to join the RIL, and the board voted to accept the application. The board also took the opportunity to recommend that some of the discussion topics be turned into a blog post clarifying some aspects of what sorts of projects would be excellent candidates for the RIL, and the staff has now done so!
The board discussed some early ideas the Foundation staff have had regarding ways to make the operation of crates.io more sustainable, in line with the OpenSSF statement the Rust Foundation signed on to in Sept 2025. No final decisions about what to implement were made, and the staff will be continuing to discuss and refine the ideas with relevant parts of the Rust Project in the coming months.
The board discussed ways to include Gold members in the board meetings while there aren't sufficient numbers to warrant a voting seat.
The board discussed some early ideas on how a Rust Ecosystem Fund could work to make it easier for companies to support the important crates they use. No decisions were made aside from agreeing that this is a topic worthwhile of further investigation by the Foundation staff.
The Processing Foundation was approved as an associate member of the Foundation.
Teor joined the C++ Interop Initiative as a contractor.
Canonical joined as a Gold member!
The Rust Foundation joined the DataDog Open Source Program, giving us a observability platform to monitor and act on infrastructure events.
The security and infrastructure team have been working to address typosquating attacks on crates.io, alongside help from the crates.io team, security response and secure code working groups.
The interop initiative has been identifying high-priority use cases to focus attention on.
A re-brand of the RustConf website for the 2026 conference has been completed (and since launched).

crates.io: Help test our new web frontend

2026-04-17T00:00:00+00:00

We have been porting the crates.io frontend from Ember.js to Svelte 5 (tracking issue), and the new Svelte app is now ready for public testing at https://crates.io/svelte/. We'd love your help trying it out before we make it the default.

The Svelte app is intended as a 1:1 port of the Ember.js app for now. It should look and behave the same (our UI test suite, including visual regression testing, already passes against both), so any significant difference you notice is a bug we want to hear about. To keep the two apps easy to compare, a few rough edges of the Ember.js app have been carried over as well. Those will get smoothed out once we are no longer maintaining two frontends in parallel.

Both apps are served from the same domain and share session state and data, so you can just visit https://crates.io/svelte/ and keep using the site normally without logging in again. If something looks or behaves differently than on the Ember.js app, please let us know, either via GitHub or on Zulip (#t-crates-io).

If testing goes well, we'll switch the Svelte app to the default in the coming weeks, and we're looking forward to what we can build on top of it from there.

We want to thank the Ember.js team for a framework that served crates.io well for many years, and the Svelte team for making the transition to something new so enjoyable. A big thank you also to @eth3lbert from the crates.io team for reviewing the bulk of the migration pull requests.

Infrastructure Team 2026 Q1 Recap and Q2 Plan

2026-04-14T00:00:00+00:00

Here's what the Infrastructure Team delivered in Q1 2026 and what we're focusing on in Q2.

You can find the previous blog post of this series here.

Q1 Accomplishments

Move to GitHub Rulesets

We started migrating from branch protection rules to GitHub Rulesets.

Rulesets are the new way in which GitHub suggests protecting branches and tags. They allow more configurability with respect to classic branch protections, and they are the only way in which you can setup new functionalities such as merge queues via API.

We converted all repositories, except for the rust repository. We are working on it!

As part of this effort, we also made all the branch protection and ruleset options we use configurable via the team repository, so that they can be managed as Infrastructure as Code (IaC).

Here are the newly available configuration options:

allowed-merge-apps
merge-queue
prevent-deletion
prevent-force-push
require-conversation-resolution
require-linear-history

For more details, see the GitHub issue.

Improved CI security

We always try to improve our security posture. Here are the most relevant examples for this quarter:

In the team repository, we enabled Renovate, a bot that automatically creates pull requests to keep GitHub Actions and Rust dependencies up to date. This makes it easier for us to keep our dependencies up to date and fix security issues in a timely manner.
In the compiler-builtins CI, we enabled Renovate and resolved the security issues reported by zizmor in preparation for running the RISC-V self-hosted runner in CI in a more secure way.
We released crates-io-auth-action v1.0.4, updating its dependencies and moving it from Node 20 to Node 24 after GitHub announced the deprecation of Node 20 on Actions runners.

Two new dev desktops

We provisioned two new dev desktops: dev-desktop-us-2.infra.rust-lang.org and dev-desktop-eu-2.infra.rust-lang.org.

We also enabled IPv6 access for dev desktops, making them easier to reach from more network environments. See the GitHub issue.

Learn more in the Forge docs.

Bigger docs.rs instance

We are experiencing an unprecedented increase in crates published on crates.io, which is putting a lot of pressure on the docs.rs infrastructure, which has to build the documentation for more crates than before.

To keep up with this growth, we upgraded the docs.rs instance to a more powerful one, doubling the available RAM and CPU cores.

Improved access controls for Rust infrastructure with SAML SSO

We introduced Google SSO as part of Rust infrastructure offerings. We enabled Google Workspace accounts for the infrastructure team and validated the SAML setup for some of the key infrastructure providers, like Datadog and Fastly.

Triagebot enhancements

Triagebot is our trusty bot incessantly processing workflows on GitHub and on our Zulip chat.

We implemented several notable changes in Q1 2026.

GitHub issue comments viewer

We've added to Triagebot a GitHub issues and PRs viewer. It's primarily designed for long issues and PRs where GitHub is unhelpful with its "Load More" button.

It can be accessed via the View all comments link at the top of long issues and PRs.

Example for triagebot#2251:

And while it started rather small in its ambitions, it evolved quite a bit over the last quarter with:

a self-contained "Export" button (implemented in #2274)
a table of contents for review threads (implemented in #2360)
expand/collapse thread buttons (implemented in #2355)
and other small improvements

Organization-wide default configuration

Triagebot has many features and configurations, and while it's not difficult to enable a feature in a repo (the cost of a PR), it doesn't scale to the size of the rust-lang organization and its >200 repositories.

In order to address the uneven availability of features across all the repositories, we've added support for organization-wide default configuration in the Triagebot codebase and started enabling some features org-wide.

Announcements of soon-to-be-enabled org-wide features are done in #t-infra/announcements>Triagebot Organization-Wide Defaults on Zulip.

`user-info` command

This new Zulip command first appeared as the comments command for viewing recent user comments, but was extended into a more general user-info command, which shows recent activity (PRs, repositories) and account creation date for the given GitHub user account.

This is part of our efforts to help reviewers and maintainers with sloppy AI-generated PRs.

Per-team rotation mode

Triagebot handles the automatic assignment of reviewers in multiple repositories. Until February, it was not possible to set per-team rotation mode.

This is now possible via the Zulip command work set-team-rotation-mode <team> off/on, implemented in #2273 by @Kobzol.

Per-repository review preferences

Continuing with the theme of reviewer assignments, it was previously only possible to set a review preference for rust-lang/rust, despite the multiple repositories handled by Triagebot.

@Kobzol fixed that in #2286. It is now possible to set per-repository review preferences.

Report banned users to moderator stream on Zulip

As part of supporting different team needs, we've implemented an automatic reporting system on Zulip for banned users in our GitHub organization (implemented in #2269).

The goal of this feature is to relieve moderators from taking screenshots and manually archiving offending comments and user actions by automatically retrieving that information and posting it in the moderators’ Zulip channel.

Clippy's Zulip lint nomination topic

Similar to the previous topic, we've also helped T-clippy set up an automatic FCP topic on Zulip when they want to nominate a lint for discussion.

As part of this work, we have also added the ability to add back a comment on GitHub with the link to the created Zulip topic.

New Zulip commands to handle backports and assign priority to issues

Project members can now use two new Zulip commands to apply labels on rust-lang/rust issues and pull requests:

backport [stable | beta ] [approve | decline ] <pr #>: to accept or decline for backport a patch fixing a regression
assign-prio <issue #> [ critical | high | medium | low | <empty>]: to assign a priority label to an issue (admittedly mostly used by the Compiler Team but it's available to everyone)

For more details, see the documentation.

Q2 Plans

Finish Q1 goals

In Q1, we didn't manage to finish all our goals, so we will continue working on them in Q2:

docs.rs infrastructure modernization: Although we made some improvements to docs.rs in Q1, such as using GitHub OIDC for publishing container images to AWS ECR, we still want to move from the single EC2 instance to a modern, managed deployment.
External hardware CI policy: Publish requirements for running Rust CI on external hardware.
Move to GitHub Rulesets: Migrate the rust repository to GitHub Rulesets.
SAML SSO:
- Enable provisioning Google Workspace accounts from the team repository.
- Onboard all users that require infrastructure access and add the SAML setup for other service providers, like AWS.

Improve CI security and developer experience

We want to keep making the CI of the Rust Project both safer and easier to work with.

We have many ideas and we're not sure which ones we will prioritize yet, but here are some examples:

Make it easier for Rust Project members to adopt tools like Renovate to keep their dependencies up to date and secure.
Check CVEs of our dependencies.
Add more static analysis tools such as zizmor to secure more CI workflows.
Improve our CI observability by creating dashboards around metrics such as CI jobs duration and failure rate. Since the Rust Foundation joined Datadog’s Open Source Program, we plan to use Datadog for this task.
Improve visibility of the test coverage of the CI jobs.

Hardware security keys for critical infrastructure access

We want to secure access to critical Rust infrastructure even further by using hardware security keys. The Rust Foundation partnered with Yubico, and we want to provide YubiKeys to the Rust teams with access to critical infrastructure.

Our plan is to distribute hardware keys in May, during the Rust All Hands. See the related GitHub issue.

Join us!

If you're interested in contributing to Rust's infrastructure, have a look at the infra-team repository to learn more about us and reach out on Zulip.

We are always looking for new contributors!

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 (Tomas) 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, Tomas 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 Tomas Sedovic. 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

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:

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

Inside Rust Blog

Program management update — May 2026

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

How Josh helps Rust manage code across multiple repositories

Problem statement

Monorepo

git submodules

git subtrees

Josh comes to the rescue

Maintainer spotlight: Tiffany Pek Yuan (@tiif)

1.96.0 pre-release testing

Program management update — April 2026

Program management schedule

The 2026 RustWeek / All Hands

Project goals

Outreachy

C++ interop update

Content team

Rust for Linux

zerocopy features in std

null-ptr-deref

Edition migration tooling

Project Director election process update

Worth a look

Rust Foundation posts

Rust Project updates

Stats

March 2026 Project Director Update

crates.io: Help test our new web frontend

Infrastructure Team 2026 Q1 Recap and Q2 Plan

Q1 Accomplishments

Move to GitHub Rulesets

Improved CI security

Two new dev desktops

Bigger docs.rs instance

Improved access controls for Rust infrastructure with SAML SSO

Triagebot enhancements

GitHub issue comments viewer

Organization-wide default configuration

user-info command

Per-team rotation mode

Per-repository review preferences

Report banned users to moderator stream on Zulip

Clippy's Zulip lint nomination topic

New Zulip commands to handle backports and assign priority to issues

Q2 Plans

Finish Q1 goals

Improve CI security and developer experience

Hardware security keys for critical infrastructure access

Join us!

Program management update — March 2026

Team meetings

Program management board

Project goals

FLS Release Notes

Mirroring crates.io and Rust releases

Rust Foundation Maintainers fund (RFMF) RFC

Outreachy internships

Rust for Linux

Rust for CPython

Drop with context

Sanitizers

Future meetings

Worth a look

Rust Foundation posts

Rust Project updates

Stats

`user-info` command