Inside Rust Blog

Call for testing: Restricting trait implementability and field mutability

2026-08-10T00:00:00+00:00

We are excited to announce that RFC 3323 "Restrictions" is ready for testing on nightly Rust. In this post, we will briefly describe the features. If you are already familiar with them, you can skip ahead to the How can I help? section.

The RFC is split into two features: impl_restriction and mut_restriction.

What is `impl_restriction`?

The impl_restriction feature allows explicit restriction of the scope in which a trait may be implemented.

For example, consider a trait Foo with a method that we want users to be able to call, while preventing downstream crates from providing their own implementations. With this feature, we can write:

#![feature(impl_restriction)]

pub impl(crate) trait Foo {
    fn method();
}

impl Foo for usize {
    fn method() {}
}

The impl(crate) restriction prevents Foo from being implemented outside the current crate. As with pub, other paths can also be specified, such as impl(super) or impl(in path).

Without this feature, this use case is typically handled using the sealed trait pattern, which is described in the Rust API Guidelines.

In short, this pattern defines a public Sealed trait inside a private module and makes it a supertrait of Foo. Because downstream crates cannot name Sealed, they cannot implement Foo.

pub trait Foo: private::Sealed {
    fn method();
}

// Implement `Foo` for selected types.
impl Foo for usize {
    fn method() {}
}

mod private {
    pub trait Sealed {}

    // Implement `Sealed` for those same types, but no others.
    impl Sealed for usize {}
}

However, this pattern requires defining an additional Sealed trait. The new impl_restriction feature provides a more direct and concise way to express the same restriction.

The feature also allows the compiler to produce a more direct error message when an implementation is attempted outside the permitted scope.

For example, the following code:

#![feature(impl_restriction)]

pub mod foo {
    pub mod bar {
        pub(crate) impl(super) trait Foo {}
    }

    // `Foo` may be implemented here.
    impl bar::Foo for i8 {}
}

// Error: `Foo` cannot be implemented here.
impl foo::bar::Foo for u8 {}

results in the following error:

error: trait cannot be implemented outside `crate::foo`
  --> src/lib.rs:12:1
   |
12 | impl foo::bar::Foo for u8 {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: trait restricted here
  --> src/lib.rs:5:20
   |
 5 |         pub(crate) impl(super) trait Foo {}
   |                    ^^^^^^^^^^^

What is `mut_restriction`?

The mut_restriction feature allows explicit restriction of the scope in which a field may be mutated.

For example, consider a struct Bar with a field alpha that can be read from any crate but can only be mutated within the crate where Bar is defined. With this feature, we can write:

#![feature(mut_restriction)]

pub struct Bar {
    pub mut(crate) alpha: u8,
}

The mut(crate) restriction prevents alpha from being mutated outside the current crate. As with pub, other paths can also be specified, such as mut(super) or mut(in path).

This provides an alternative to getter methods by allowing read-only access through direct field access. It can also work better with the borrow checker, which can track borrows at the field level and allow disjoint fields to be borrowed independently.

When code attempts to mutate a restricted field outside the permitted scope, the compiler produces a direct error message. For example, the following code:

#![feature(mut_restriction)]

pub mod foo {
    pub struct Bar {
        pub mut(self) alpha: &'static str,
    }

    impl Bar {
        pub fn mutate_inner(&mut self) {
            // `alpha` may be mutated here.
            self.alpha = "inner";
        }
    }
}

impl foo::Bar {
    pub fn mutate_outer(&mut self) {
        // Error: `alpha` cannot be mutated here.
        self.alpha = "outer";
    }
}

results in the following error:

error: field `alpha` cannot be mutated outside `crate::foo`
  --> src/lib.rs:19:9
   |
 5 |         pub mut(self) alpha: &'static str,
   |             --------- field restricted here
...
19 |         self.alpha = "outer";
   |         ^^^^^^^^^^^^^^^^^^^^

The mut_restriction feature can also be used with fields of enum variants and unions. For example, we can write:

pub enum Foo {
    Alpha { mut(crate) x: u8 },
    Beta(mut(crate) u8), // We can also use tuple-style
}

pub union Bar {
    pub mut(crate) i: i32,
    pub f: f32,
}

pub struct Baz(pub mut(crate) u8); // We can also use tuple-style

Restricting construction with struct expressions

A common reason to use mut-restricted fields is to preserve an invariant. However, allowing unrestricted construction with struct expressions would let users create values that have not been validated, potentially violating that invariant.

Thus, we disallow struct expressions if any mut-restricted field cannot be mutated from the current scope. For example, the following code:

#![feature(mut_restriction)]

pub mod foo {
    pub struct Baz {
        pub alpha: u8,
        pub mut(self) beta: u8,
    }
}

fn main() {
    let bar = foo::Baz { alpha: 0, beta: 1 };
}

results in the following error:

error: `Baz` cannot be constructed using a `struct` expression outside `crate::foo`
  --> src/main.rs:11:15
   |
 6 |         pub mut(self) beta: u8,
   |             --------- field restricted here
...
11 |     let bar = foo::Baz { alpha: 0, beta: 1 };
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

How can I help?

We'd love for you to try out these new features and share your feedback! To get started, use the latest Rust nightly compiler¹ and enable #![feature(impl_restriction)] or #![feature(mut_restriction)].

Please share your feedback in the dedicated feedback issue.

In particular, the RFC lists several unresolved questions. One of the main open questions concerns the syntax, which is still open to discussion. Please try out the features and let us know what you think!

Acknowledgements

These features were implemented as part of a Google Summer of Code 2026 project. I would like to thank my mentors, Jacob Pratt and Urgau, for their guidance and support throughout the project.

Make sure to run rustup update nightly first, as these features are very new and may not be available on an older nightly toolchain. ↩

rust-lang/rust is adopting an LLM policy

2026-08-05T00:00:00+00:00

Recently, five teams in the Rust project adopted a policy that I originally authored, governing how Large Language Models can be used when contributing to the rust-lang/rust monorepo. Notably, the new policy is not an official stance on LLMs, and does not apply everywhere in the Rust project. I wrote it for a very specific purpose, described below.

This post talks about why we created that policy, what it says, and how this will affect contributors.

The policy affects the following groups of people:

People who review or moderate PRs on rust-lang/rust.
People who author PRs with LLM-generated code on rust-lang/rust.
People who discover issues using LLMs and post them on rust-lang/rust.
People who write issues or comments that directly quote an LLM on rust-lang/rust.

If you are not in one of those groups, you don't have to change anything about how you work.

Why was this policy created?

While the Rust project is a collection of technical artifacts, it is also a community of people who work together to build, maintain, and extend those artifacts. When we talk about "contributing to the Rust project", we partly mean work on those artifacts, but we also mean joining that community and collaborating with the people already there.

Even before this policy was created, people were using LLMs to contribute to rust-lang/rust. Some of those uses respected our community: translating messages to English so people could draft them in their native language; finding poor diagnostics for code snippets that new contributors to Rust might write; analyzing RFCs to see if they were missing a discussion of other parts of the language that could affect the design. Some of those uses, sometimes unintentionally, did not.

I've seen LLMs causing three main issues for our community:

Polished technical products no longer indicate effort and understanding.
Making code easier to write exacerbates our existing issues with review bandwidth.
People mechanically copy-pasting to and from an LLM is a waste of our time.

As time went on, these issues grew and grew, until we had to create dedicated channels and moderation policy for how to deal with them. However, those channels work against our goals of being transparent and welcoming, because new contributors have no idea what the rules are.

The new policy formalizes those rules publicly, so that new contributors know how to join our community without getting their PRs closed for reasons they don't understand, and so that existing reviewers can easily point to the rules as an actionable reason when closing PRs that don't follow them.

Technical products no longer indicate effort

It used to be that if an open source project got a polished, well-tested, detailed PR, that indicated that there was someone on the other end who had put time, effort, and understanding into the PR. That influenced Rust's culture in several ways:

We are generally reluctant to close PRs, since they represent someone else's hard work.
Our process emphasizes incremental discussions, where PRs are allowed to change existing design if we discover new facts during creation or review.
We treat PRs as an indication that someone is interested in joining our community and being mentored to work on future PRs.

With LLMs, none of these signals are reliable. Polished PRs no longer indicate effort; authors of polished PRs no longer necessarily understand their code—and in the case of autonomous agents, there is no longer someone on the other end at all; and because it's become so much easier to write code, a polished PR no longer indicates that someone is likely to stick around for the long term.

Making code easier to write causes review issues

At the time of writing, there are 1,281 open PRs to rust-lang/rust. This represents a staggering amount of time invested by both authors and reviewers. We have long had the problem that there are more people who want to write code than people willing to review it. With the advent of LLMs, this problem only gets worse.

Most of the work of reviewing is not simply catching bugs. A great deal of it is deciding whether this direction is a good approach, whether the PR is a good idea at all. In other words, reviewing is made of decisions.

"Shotgunning" PRs at reviewers incurs a high mental cost for them. I think most authors of LLM PRs believe that they are sincerely helping, but from our perspective, the code itself is the smallest and in some ways least important part of the change. We care much more about authors understanding what the code does, planning how it will change in the future, and deciding what it should look like. The code itself cannot help with any of those.

Mechanically copy-pasting LLM output is a waste of time

We will often get people who respond to review comments by copy-pasting them into their LLM, then copy-pasting its response back onto GitHub. Bluntly: this is a waste of everyone's time. If we wanted an LLM's opinion, we could have asked it ourselves. We want to hear your thoughts, not a machine's.

Moreover, this is a breach of trust between the reviewer and the author. Our assumption when we review is that we're talking to a real person who wants to do their best work. Pasting LLM text creates suspicion: does the author actually care? Is there a person here at all?

So why a policy?

Before this policy, we had a "wild west" approach to moderation. We had dozens of LLM PRs; no disclosure rules; people trying to add risky MIR optimizations as their first PR; and people posting "Verification: git diff --check" in their PR description as if that did something. While we had something for moderators to point to in the form of "Empower reviewers to reject burdensome PRs", our enforcement was inconsistent and our rules were not published anywhere. In practice, the rule was "anything goes, as long as it's not obviously horrible". Compared to the previous situation, the new policy is both much more strict and much more clear.

Regardless of your opinions on whether LLMs are good, bad, or a secret third thing, they can no longer be ignored. Our choices are not "no policy" or "policy". Our choice is whether to have the policy be an unofficial list of moderation notes or something we stand by publicly.

Why not ban LLMs altogether, or allow any use of LLMs that we think are pro-social? Because Rust governance doesn't work that way. We do not have a benevolent dictator who can say "No LLM-generated content, whether it be code or prose." or "AI is a tool, just like other tools we use".

Rust operates by consensus. As the policy says:

There is not a consensus within the Rust project—and likely never will be—about when/how/where it is acceptable to use AI-based tools. Many members of the Rust project and community find value in AI; many others feel that its negative impact on society and the climate are severe enough that no use is acceptable. Still others are working out their opinion.

Despite these differences, there are many values we all share:

Building a community of deep experts in our collective projects.

Building an inclusive community where all feel welcome and respected.

We want it to be possible to change the policy in the future. The policy has several provisions that make it easier to change than it was to originally adopt. The leadership council is also considering creating a sub-team that would handle LLM policy so we have fewer "nightmare" 30-person approval requirements.

I do not think every rule in this policy is wholly good. I do think that writing our rules down is better than not writing them down, and that having a policy that everyone kinda dislikes pushes us to improve our governance structures.

What does the policy say?

The policy summarizes itself this way:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

Uses in the first category are allowed, sometimes requiring disclosure. Uses in the second category are heavily restricted.

General rules

No one except the author is required to read LLM output unless they choose to: LLM output isn't allowed in public docs, PR descriptions, or Github comments unless it's clearly marked; reviewers aren't required to look at LLM PRs if they don't want to.

No one is required to use LLMs to contribute to rust-lang/rust: policies must be written first for humans, and only summarized for machines; LLM reviews cannot substitute for human review or self-review.

You are allowed to generate LLM content that only you see, without disclosure, as long as you do not post it anywhere that you expect us to read or review.

Disclosure is required for machine translation, "trivial" changes, discovering bugs, and reviewing other people's work using an LLM. We welcome messages posted in your native language; English translation is not required to contribute.

There are very strict guidelines on LLM-generated code changes:

Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.

The policy holds LLM-generated changes to a higher bar than human-authored changes, not a lower one: LLM PRs are required to have tests, full stop, regardless of how hard that is, as well as various other restrictions; LLMs must not generate soundness-critical changes unless the author is already a domain expert, and even then it's strongly discouraged.

In general, the policy focuses on understanding, helping to ensure that we have a mental model of our code, not just artifacts that mechanically do the right thing. Our motivation is influenced by Profession by Isaac Asimov. No programmer tapes.

Moderation rules

You must disclose LLM-generated content. You can choose to not post LLM content, or you can choose to post it and disclose its origin. You may not hide LLM involvement.

Harassment is not allowed. You may not harass people for using an LLM, regardless of whether or not their use is banned by the policy. You must follow the Code of Conduct at all times when interacting with the Rust project.

See the policy itself for more information.

Some parts of the policy are unenforceable. This is not a bug. The goal is not to catch every violation, but to create a clear bright-line rule: Disclosure is required for all public LLM text, unless specifically exempted by the policy. This allows moderators to identify violations based on actions, not on intent, and only consider intent when deciding how to respond.

How does this affect contributors?

Issue reporters

You must disclose any LLM involvement in discovering or reporting issues. You must tell us if you found an issue using an LLM. You must clearly quote and indicate which parts of your report were LLM-generated; the "no LLM-generated comments" rule applies to you too.

Authors who post LLM-generated code

I have written a list of guidelines you should follow if you make a PR to rust-lang/rust with LLM-generated code. You can avoid thinking about them, or indeed reading the list at all, if you follow this simple guideline from the policy:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

See the "Allowed" section of the policy for a full list of what's meant by that. See rustc-dev-guide for the full list of guidelines.

Reviewers

General review

You are allowed to close PRs that don't follow the policy, no questions asked. Please point the author to #llm-mentoring at the same time. See the dev guide for exact circumstances and suggested wording.

You are not responsible for determining whether a PR is LLM-generated; that responsibility lies with the author. We will add a PR template that asks authors whether their code was LLM-generated so that this rarely comes up.

If an author claims their code is not LLM-generated, but you're still not sure, please report the PR privately to moderation. Style is not evidence; please do not accuse people of using an LLM. Reporting is not intended to be a penalty; the mod team is interested in seeing non-violations as well as violations.

Review of LLM code

If you have volunteered to review LLM PRs, the following section applies to you. No one is required to review LLM PRs unless they volunteer.

Everyone is expected to follow the new policy, not just authors. That means it is your responsibility to check whether an LLM-created PR touches an area that's disallowed by the policy, such as docs, diagnostics, or soundness-critical changes. You may request that the author redo it without LLM-generated code, in which case this section doesn't apply.

There's a more detailed summary of the rules you're expected to enforce in the dev guide. The official policy remains canonical.

What next?

Quite a lot of work has been put into this by moderators, team leads, reviewers, council representatives, and various other people inside and outside the project. Some of that work started months ago before the policy itself was written. I'd like to thank everyone who contributed, whether directly or indirectly.

This is not the end of the story. One of the goals of the policy is to help us gather data: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? The answers to those questions will help us determine how the policy changes in the future.

This is not the first LLM policy published by teams in the Rust project, and hopefully it will not be the last. While the current policy only applies to the rust-lang/rust monorepo, I still believe that Rust would benefit from a project-wide policy that specifies what we expect in chats, forums, public communications, repositories without an explicit policy, and other cross-project areas.

Funding team progress update — July 2026

2026-08-04T00:00:00+00:00

Hi all! This is an update from the funding team. Established by the leadership council, the funding team is tasked with administering the Rust Foundation Maintainers Fund. Per RFC #3931, our initial focus has been on establishing the Maintainer in Residence (MiR) program. The goal of the MiR program is to offer a long-term, stable option to support people doing maintenance work.

While RFC #3931 laid out the high-level structure of the program, going from the "idea" of a Maintainer in Residence program to an actual functioning entity involves a lot of small decisions. This post covers the questions we've been discussing. For some of those questions, we have preliminary decisions, for others we are still deliberating. In any case, we welcome your input.

Funding total

We have so far received generous donations totaling $350K. We'll go into details on the sponsors when we announce our first Maintainer-in-Residence.

Want to help? You can sponsor the Rust Foundation Maintainers Fund directly on GitHub Sponsors. For companies and larger donations, reach out to funding@rust-lang.org.

We're also brainstorming ideas for an individual fundraising campaign to help grow the fund; if you'd like to pitch in ideas or follow along, join the discussion on the funding stream on Zulip.

Gathering details: what we learned

We sent out messages to existing Rust team members asking people to fill out a form if they were interested in being supported by the funding team. We heard from 45 individuals looking for funding and 3 teams gave us a general update.

Broken out by area (with some double counting as some individuals opted for more than one area):

Area	Count
compiler	21
libs	4
clippy	3
rustdoc	2
a-mir-formality	1
cargo	1
crates.io	1
infra	1
lang	1
mods	1
Rust Analyzer	1
rustup	1
Safety Critical Rust Consortium	1

Of the respondents, 34 indicated interest in a general maintenance (MiR) role and 13 indicated interest in being funded towards specific project goals (some people indicated both). We also asked about desired arrangement and compensation; as expected, there was a wide variance, with many preferring full-time employment but also many looking for contracts or part-time work.

2025 survey results show the need is real

There is a definite need for funding. In November of 2025 we ran a survey amongst active Rust maintainers. In that survey we found that 35% of contributors who filled the survey are currently funded for their Rust contributions (and this also includes people who only receive a minimal monthly amount e.g. through GitHub Sponsors). A similar number of people (~35%) never received any funding for their upstream Rust work. Even though many of those people are not funded at all, the average number of hours spent by a Rust Project contributor on improving Rust is around 40 hours each month!

Hashing out the details of the MiR program

The goal of the MiR program is to provide open-ended funding to support Rust maintainers and by proxy also the Rust teams that they operate in. As we discussed in our blog post "What is Maintenance, anyway?", the precise needs of teams vary, so this can be tricky to define.

The important thing is that MiRs help "enable other contributors to evolve and improve the project". For some teams, this might mean helping to run triage meetings, or burning through a PR review backlog. For others, it might mean focusing on a big refactor that everybody on the team knows is necessary, but nobody has the time to do.

General shape: year-long contracts with expectation to renew

To begin with, the MiR program will consist of year-long contracts that come with the expectation but not guarantee that they will be renewed year-over-year. It's too early in this program to judge how stable our funding will be and thus we are not able to make long-term promises around renewal.

Flat rate or negotiated rates? One of the obvious questions that had to be decided is whether we should pay all Maintainers in Residence the same rate or whether we should negotiate on a case-by-case basis. We've decided to start with a flat rate, independent of geography. This is more transparent and easier to administer. It avoids questions of unfairness where someone is getting paid more because they're a better negotiator or because of where they live. On the flip side, it does mean that the MiR program will not be a good fit for people who live in expensive areas or who are looking for a higher salary than what we offer.

How much to pay? The next question of course is how much to pay. We looked at the incoming data that we received on what rates people are looking for, both in our recent survey as well as the November of 2025 survey, and also looked at comparable setups at other foundations (e.g., Zig). We've settled on the following flat rates, though in individual cases we may make small adjustments. Note that we've opted not to document this as an hourly rate, but rather a monthly rate with various levels of expected activity. This is because we don't intend to have people submit hourly reports to account for their time.

Activity level	Rate per month
Full time (~40h/wk)	$10K USD
Half time (~20h/wk)	$5K USD
Day (~8h/wk)	$2K USD
Half-day (~4h/wk)	$1K USD

Note that these are the amounts the Rust Foundation pays to the person or entity taking on the work; they are not a gross salary or take-home figure, and how they translate to net pay will depend on your situation and jurisdiction.

Exclusive? The MiR contracts are not "exclusive" so if a MiR wishes to take additional contracts on the side, that is fine, so long as they do not interfere with their ability to do maintenance work as discussed above.

Under discussion: Off-ramp period. As noted earlier, we expect to renew MiR contracts year over year but we are not in a position to guarantee that. Therefore, we are considering including a certain amount of "padding" in our budgeting so that if we are not able to renew the contract after one year, we can give MiR recipients an "off-ramp". The idea would be that if we are not able to renew the contract for another year, we can give a short-term payout to help cover expenses (and any maintenance they may choose to do...) while they find a new role. The goal is that MiR recipients can focus on maintenance worry-free for one year, even if funding is not renewed. Questions to be decided:

Do we do this off-ramp? We want to, but it does mean that we have fewer total MiRs.
Do we do this off-ramp for everyone? We are thinking we would offer the off-ramp only to full-time MiR (or perhaps full- and half-time), since if the MiR is only covering a day, that implies that the MiR is less dependent on the salary.
How long is the off-ramp? Our initial thought was 25% (3 months), but shorter would mean we can fund more work.

Why not employment? For many people, employment is the ideal setup (though by no means everyone), but we are not in a position to offer it at this time, because employment requires ongoing funding. As the MiR program evolves, we hope to be able to support long-term employment for established Maintainers in Residence, but that is something we'll have to figure out as the program matures.

How do we decide where to fund a MiR role?

We decided that rather than starting with individuals seeking funding, it was better to look at the teams that need funding first. But we know we're not going to be able to provide for all the teams at the level we would like to. Therefore, we wanted some rubric for how we prioritize which teams to fund. We settled on the following axioms that we can use to guide decisions:

End-user impact first. We prefer to fund maintenance of areas that have a real (direct or indirect) impact on Rust users' experience.
Dire needs first. Address the teams with the greatest need first — raise the floor before raising the ceiling.
Fund what no one else will. We lean toward maintenance, review, and triage: work with no natural corporate sponsor and no realistic path to directed funding.
Scale to demand. For areas with lots of potential for directed funding, we still want to fund maintainers to keep the code healthy between feature work.
Shovel-ready. Between equal-priority needs, we start with the one that can begin the soonest.

These axioms are written in priority order and they're meant to help us resolve tough decisions. For example, if we have to pick between two teams, both of which have dire need, but one of which has more visible end-user impact, we'll pick the one with more visible end-user impact because that will help us in raising additional funding later. (At the same time, these are rough guidelines, not iron laws: there may be particulars of the situation that lead us the other way.)

Short-list of teams. Based on the identified criteria, we are focused first on the following teams: rustup, rustfmt, clippy, rustdoc, libs, cargo, and mods (in no particular order).

Under discussion: what if there are no MiR applicants? There are teams that we would like to support but where none of the existing team members are interested in a MiR role (perhaps they have another full-time job or just like working on a volunteer basis). We are discussing how best to manage this situation when it arises. For example, we might approach the team and see if there are any active contributors they would support for a MiR role or perhaps put out a call for applications.

Restricted funding. So far, all the funds in the MiR were given unrestricted, which means that the funding team and the project can decide how to spend them. However, we have also had sponsors raise the idea of restricted funding, where a sponsor wants to fund a MiR for a particular team (say, rustfmt, or cargo) because they are concerned about that area, or even wants to fund a specific individual who they know does good work. We decided that we would happily accept restricted funding so long as the person is being funded to do maintenance work and generally treated like any other MiR.

What comes next?

This is our overall roadmap:

Rust Foundation: Announce program and begin fundraising
Leadership Council: Establish funding team and outlines of the MiR program (RFC #3931)
Funding team: Gather information on who is looking for funding and what work they'd like to do (👈 subject of this update)
Funding team: Hash out the details of the MiR program (👈 subject of this update)
Funding team: Narrow down to a short list of candidate MiRs and begin individual discussions (currently ongoing)
Funding team: Announce MiR selection (hopefully coming soon!)
MiRs: Do your thing.

At this point we have assembled a short list of candidates for our initial round of MiRs and we are planning to begin discussing specifics with them. This will help us to narrow to the final list. We are aiming to have that list announced by the end of August.

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)¹. 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². 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³ and reborrowing⁴ (1, 2, 3), in-place initialization, SIMD, allocators⁵, custom lints, stability attributes for libraries, rustc as a library⁶, 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⁷, the state of Rust/C++ interop using Crubit⁸, 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⁹ 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 ↩

Infrastructure Team 2026 Q2 Recap and Q3 Plan

2026-07-15T00:00:00+00:00

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

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

Q2 2026 Accomplishments

GitHub Rulesets are now the default protections

We migrated the rust-lang/rust repository to GitHub Rulesets and finished moving off the legacy GitHub branch protections. Rulesets are now the default way to configure protections for rust-lang repositories through team.

GitHub apps are now enabled through team

We re-enabled the ability to install GitHub apps in rust-lang repositories through team. This improves the developer experience for contributors and reduces the operational overload for Infrastructure Team members.

Shared Renovate Presets

Renovate is the tool the Infrastructure Team recommends to the Project for keeping dependencies and GitHub Actions up to date.

We created shared Renovate presets to simplify the Renovate configurations of the rust-lang repositories. These presets aim to get the benefits of dependency updates while minimizing the number of PRs to review. We also documented how to adopt Renovate in repositories.

Code security for rust-lang repositories

As part of our security work, we enabled GitHub Secret Scanning for all rust-lang repositories. We triaged all alerts tagged as leaked secrets and confirmed that they were false positives.

In addition, in collaboration with the crates.io team, we started experimenting with Datadog Code Security to get additional visibility into security issues inferred directly from source files. We documented how to opt into this feature, and we want to try it with more repositories in the future. This work is a follow-up of the Rust Foundation partnership with Datadog.

New GitHub Actions runners powered by external hardware

We enabled new powerpc64 and RISC-V GitHub Actions runners for rust-lang repositories. We also documented which external runners are powered by external hardware and where they are used in rust-forge.

In addition, we created a new infrastructure guideline to help onboard external hardware into the Rust CI infrastructure.

Experiments with macos-26 on CI

We started experimenting with macos-26 in rust-lang/rust CI. We created an additional CI job and have been tracking how it performs. It's worth mentioning that GitHub will migrate all macos-latest images to macos-26 in June and July.

CI dashboard available again

In December 2024, we created a Datadog dashboard to track CI visibility for the rust-lang/rust repository. It proved very valuable, but we had to remove it because its cost was not sustainable.

Now that the Rust Foundation is part of Datadog's Open Source Program, we enabled it again.

In the past, the dashboard helped us track the top failing jobs, slowest jobs, and overall pipeline duration over time. We expect it to be just as useful going forward.

Hardware Security Keys for critical infrastructure access

We introduced official support for hardware keys as part of the Rust infrastructure security processes. We created a policy mandating multi-factor authentication with hardware keys for people and teams with access to systems considered critical, and in partnership with Yubico we empowered Rust Project members with YubiKeys.

We also documented how Project members can configure these devices for existing use cases. We want to expand this support further, enabling new ways to use the keys.

Partnership with Canonical and Ubuntu Pro for EC2 instances

As a follow-up to Canonical joining the Rust Foundation in March, we got access to Ubuntu Pro licenses and applied them to our EC2 instances, including the instance running docs.rs.

We improved our Infrastructure as Code setup to apply these changes, so that Ubuntu Pro will be enabled by default even in future instances.

Faster mergeability checks in Bors

We switched from GitHub's REST API to the GraphQL API and cut Bors pull request mergeability check times from an average of 30 minutes to just 1 minute.

Add the concept of community reviews before PR assignment

As part of multiple discussions that happened during the 2026 All-hands, the Clippy team asked the Triagebot team to be able to delay the assignment of a reviewer until one or multiple community reviews were done.

That work was carried out in triagebot#2426 (docs) and has just been enabled in the Clippy repository.

Reintroduce delegation approval for merge queue repositories

When we switched our repositories to GitHub merge queues instead of bors (our custom merging bot), we lost the ability to delegate approval on behalf of the reviewer.

That functionality is quite useful when there are only some nits left and the reviewer feels confident about the author's ability to resolve them without having to re-review and approve the changes.

Work was carried out in triagebot#2412 and triagebot#2436 to add such functionality back. It's currently only enabled in the Clippy repository:

@rustbot delegate[=@handle]
@rustbot merge

Continue supporting the moderation team with locking/unlocking of issues

As part of the effort to help the moderation team better moderate issues and pull requests in our different repositories and organizations, triagebot gained support for locking and unlocking an issue/PR from a GitHub command and Zulip DM.

Quality of life improvements in our range-diff viewer for GitHub PRs

We landed multiple quality of life improvements in our range-diff viewer for GitHub PRs.

Filtering of context-only hunks

As part of our range-diff, we try as much as possible to only show the relevant parts of a diff. Context changes (lines that changed on main only) are not relevant, and we made a significant effort to filter them out from the shown diff.

More details are available in triagebot#2398.

Commit messages diff

Our range-diff now shows the list of commits and diffs them with the previous ones.

New commits:

Warning against Unicode Bidi characters

Following what GitHub does when it detects Unicode Bidi characters in a PR diff, we now also warn since triagebot#2440.

Small tweaks to the triagebot

A new triagebot command to assign a priority value to regressions directly from Zulip, useful when doing triage. Example:

@**triagebot** assign-priority 123456 high

Minor tweaks (in b1e783a2 and 6611570e) to the triagebot backport and user-info commands, which now support shorter variants:

# Supported syntaxes for the `backport` command
@**triagebot** backport accept beta 123456
@**triagebot** backport accept beta
@**triagebot** backport accept

# Supported syntaxes for the `user-info` command
@**triagebot** user-info https://www.github.com/apiraino
@**triagebot** user-info apiraino

Q3 2026 Plans

Finish leftover work from Q2

In Q3, we will continue working on some of the things we could not finish in Q2:

Improve access controls for Rust infrastructure with SAML SSO.
Modernize the docs.rs infrastructure.

Improve GitHub Actions security

We've been actively working on GitHub Actions security through our Outreachy mentorship program. This effort started in April when we adopted zizmor as a Static Application Security Testing solution for GitHub Actions in some of our repositories.

As a follow-up of one of our Rust All-Hands sessions, we started working on a system to foster zizmor auditing and progressive adoption across the rust-lang organization.

Move mailing lists from Mailgun to Google Groups to reduce spam

As a follow-up to setting up the Google Workspace for the Rust Project, we want to evaluate whether Google Groups can reduce spam for existing mailing lists, which are currently managed through Mailgun. We want to keep the same developer experience by provisioning these new mailing lists through team. If the results are satisfactory, we will also migrate existing lists.

Consolidate logs on Datadog

As part of our efforts to improve observability, we want to consolidate all log management in Datadog. Next, we want to push logs from all services into it, including those from our bots (triagebot, bors, etc).

Reduce reliance on external resources in CI

We want rust-lang/rust CI to depend less on third-party services during builds and tests. When CI downloads required artifacts from external sources, an outage in those services can cause failures unrelated to Rust itself.

To make CI more reliable, we plan to mirror more of those artifacts in the Rust project's CI mirrors.

Stricter networking access rules for crater agents

As discussed during the Rust All-Hands, we want to improve the security of crater agents by isolating their network access.

Start planning for GitHub REST API upgrade

The current GitHub REST API version ("2022-11-28") will be deprecated in about 2 years (see the GitHub announcement). We pinpointed it in our GitHub client and plan to start testing the new version ("2026-03-10") and see what it breaks.

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!

1.97.1 pre-release testing

2026-07-15T00:00:00+00:00

The 1.97.1 pre-release is ready for testing. The release is scheduled for July 16. 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-07-14/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.

Rustup 1.29.1 beta: call for testing!

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

We are excited to announce that rustup 1.29.1 beta is now available for testing and we are currently looking for testers.

What's new

The headlines of this release are:

Concurrency in certain rustup operations has been improved:
- When running rustup update, rustup will first check for possible updates in parallel. pr#4752
- When running rustup component add with multiple components, they will be installed concurrently. pr#4790
Implicit installation of the active toolchain in rustup-init and rustup invocations has been deprecated where deemed unnecessary and will now produce a warning. pr#4840
- Please see our blog post for more details regarding this change.
Installing i686-pc-windows-* host toolchains on 64-bit Windows now requires --force-non-host. pr#4935
A bug has been fixed which might cause Windows installation to fail when using rustup-init.sh. pr#4756
"Target triple" has been renamed to "target tuple" across the project to reflect the new terminology. pr#4743 pr#4827 pr#4834
- Please note that this is not a breaking change in the CLI since the existing options such as --target are not using this terminology.

In addition, rustup now officially supports aarch64-pc-windows-gnullvm as a host platform. pr#4523

Further details are available in the changelog!

As usual, we would be happy to receive regression/breakage reports of any kind.

How to test

To begin testing this new version, all you need to do is simply switching to the dev environment by setting the following environment variable when updating or installing rustup:

RUSTUP_UPDATE_ROOT=https://dev-static.rust-lang.org/rustup

To switch out of the dev environment, just remove that environment variable and do a rustup self update.

Program management update — June 2026

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

Program management update — June 2026

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

Maintainer spotlight: Gen Li (@rami3l)

2026-07-07T00: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. You can find the previous post here. Consider donating to the Rust Foundation Maintainers Fund if you'd like to support Rust Project maintainers.

In this post, we would like to introduce Gen Li (@rami3l). Gen started contributing to Rust around four years ago. In 2023, he joined the Rustup team, and in 2025 he became the lead of this team. Apart from working on Rustup, Gen Li also mentored several Rust contributors as a part of Google Summer of Code (GSoC).

We interviewed Gen to find out how he joined the Rustup team and what are his thoughts on coding as a social activity. Read more below!

Can you briefly introduce yourself?

Hi, my name is Gen Li. I come from Chongqing, an industrial city in southwestern China. I studied engineering and computer science at École Centrale de Pékin in Beijing, and I also went through a study exchange program in France, where I studied at the Centrale Nantes engineering school. After I graduated, I worked in China for a while, and last year I moved to Paris, so now I am based in France.

How did you start with Rust?

During my university studies, I was working with Python a lot, mostly to automate various processes, such as analyzing lab data. I got annoyed by Python a little bit, because it was hard to write correct code, and the package management story at that time was quite confusing¹. When I wanted to dive deeper and figure out how things in Python are actually implemented, I realized that it is often done in other languages, such as C, Cython or Fortran, which seemed quite complex.

In 2019, my friend @lynzrand introduced me to this cool new language that he has been playing with. I decided to try it, and then took it as a personal challenge to try to learn all the new concepts that I found in Rust. My first experience of building something serious in it was helping that friend build a component for an online service used for teaching classes.

What impressed me a lot about Rust was the whole developer experience and its tooling, such as the compiler or Cargo. Especially the whole unified process of creating, packaging and shipping a Rust project and the great documentation and error messages that guide you along the way.

I also examined other technologies and spent a lot of time learning (and fighting!) their tooling, and found that Rust really hit the sweet spot, so I decided to stick with it.

How did you get involved with the Rust Project?

I wanted to explore what it takes to create good tooling, and what makes Rust such an extraordinary experience. What I found great is that software in the Rust Project is written in Rust wherever possible, which means that it is not necessary to master multiple languages to make adjustments to the toolchain, and every improvement that we make to Rust then directly helps its contributors, which is something that I am really fond of.

My first contribution was to the wider Rust ecosystem. When writing a small Rust automation tool that used clap for argument parsing, I found out that clap had a bug. I was able to investigate it and fix it, so I was able to make a meaningful contribution to clap. Contributing to this project also led to my first interaction with Ed Page, a member of the Cargo team, who maintained clap.

That was a really nice experience, so I wanted to contribute more to "famous" Rust projects. I continued with scratching my own itches, so after I found a bug with derive expansion in Rust Analyzer, which I was using daily, I sent my first pull request to the upstream Rust toolchain. At that time, I was still a "drive-by" contributor, mostly fixing the bugs that bothered me, but I eventually wanted to participate more.

How did you join the Rustup team?

Weihang Lo, a Cargo contributor who organized a large Telegram Rust community that I was a part of, told me that the Rustup team was in danger. That was surprising to me, because at that time I thought that Rustup was very stable and that it doesn't need any new development, and could stay as-is "forever". Of course, now I know that is not the case.

Robert Collins, the only Rustup team member at that time, was calling for help. Given that I already had an intermediate knowledge of Rust, I thought that I could probably help maintaining it to get it out of the hardship that it was experiencing at the moment. So I contacted Robert and tried to do some basic maintenance tasks, starting from trivial fixes, and later also implementing larger features.

A few months later, I was invited to the Rustup team, together with Dirkjan Ochtman, a very experienced Rust maintainer. Together, we kind of restarted the maintenance of Rustup, and we have been maintaining it ever since. In 2024, Chris Denton joined the team, bringing invaluable Windows expertise.

How did joining the Rustup team affect your perspective on it?

Rustup is a crucial component of the overall Rust developer experience, which excels thanks to different tools (compiler, Cargo, Rustup, etc.) being tightly integrated and working well together. Contrary to what I used to think, it actually requires quite a lot of maintenance! We have to keep up both with changes to the Rust toolchain and its components, but also changes to operating systems. We also try to optimize its performance, due to the list of components and Rust targets growing over time, both in size and count. It is not possible to simply stick to what was done in the past ten years; we constantly have to adapt. This was a big mental shift for me.

Another thing that surprised me was the social aspect of contributing to open source. I used to think that the Rust Project had to be managed by some mysterious mechanism that I didn't understand, which would organize and structure work and provide resources to contributors. I learned that this is currently far from reality, and that almost everything is self-directed. For anything to happen, someone has to actively produce an effort to do it. Everyone is focusing on the one aspect that matters to them, and there is essentially no top-down management.

In general, I am happy that I am a member of the Rust Project, because I love helping other people out and volunteering, but it is also an incredible learning experience for me. I am constantly learning new things, even about Rustup and its various subsystems, which were developed over time by many people before me.

What have you been up to in the Rustup team since you joined it?

Between 2023 and 2025, it seemed that little has changed with Rustup, despite several new releases and minor bugfixes being released. However, in reality, we have done a lot of refactoring and modernization work, such as reworking the logging system and finalizing the migration to tokio, which was possible thanks to Robert's prior efforts. This work was quite important for the long-term health of Rustup's codebase, although most Rust users probably did not notice any changes during this period, because it all kind of happened behind the scenes.

In 2026, we have finally started shipping user-visible UX improvements, such as the new command-line interface style and toolchain installation acceleration, which has received a lot of praise from the community. It should be noted that these changes simply wouldn't be possible without the aforementioned maintenance groundwork. It is this long-term work that has brought us the nice results we see today, and I really wish to make that sustainable.

In the past two years, you were a mentor in the GSoC program. What was that like?

Even though the Rustup team is now in a better state than it was a few years ago, we still need to find new contributors to meet the ever-growing demand for new Rustup features and improvements, and to reduce our bus factor :) That is why I decided to participate in Google Summer of Code last year, as it is a great opportunity to onboard new contributors, and it makes me very happy that I can mentor them. While I could implement a new feature myself, it is much better to guide someone to work on it.

I'm very happy that last year we found Francisco Gouveia, whose GSoC project was focused on making Rustup concurrent and thus making toolchain installation faster. This project had great results, and helped optimize Rustup downloads across the globe. Francisco has been super helpful all along the project, and we saw a lot of potential in him, which is why we invited him to join the Rustup team after his GSoC project concluded. That is a real success story! Now I am looking forward to this year's GSoC project.

I am constantly learning new stuff while mentoring, which is great. I also learned that mentoring is all about communicating, and it helped me improve my responses in various situations, both professionally and personally.

You seem to have a lot of things on your plate. How do you find the time to contribute to Rust?

That's not an easy question to answer for me. On the one hand, Rust has always been my passion, and I am still very motivated to contribute, which is also why I constantly come back to help with various things, even at weekends or during the night. I also have many ideas on what to improve in Rustup if I had enough time for it, e.g. implementing toolchain deduplication or repairs.

But on the other hand, after my graduation, I have to prioritize my professional life, and also life outside code. I still have some spare time, but it is very hard to find long uninterrupted time slots that would allow me to focus on complex fixes or even major redesigns of Rustup to address some of its long-standing problems.

I know now that the risk of open source burnout is real. Sometimes things feel stressful and unpredictable, and it sometimes comes to me that holidays don't actually feel like holidays anymore, because I have to bounce between multiple things.

Currently, I am actively looking for opportunities to find funding for my work on Rustup, and potentially also other relevant projects that I could help out with, such as bootstrap (the Rust compiler build system) or the release process of the Rust toolchain.

What advice would you give to someone who would like to contribute to Rust?

For a start, it is good to start engaging with the Rust Project! Even if it is a small thing. I know many contributors who started their stories by fixing small issues that bothered them, such as making typo fixes or documentation enrichments, and later expanded to work on larger features. When your contribution resolves a real problem for your usage of Rust, it will give you more motivation to work on it. My contribution journey started by fixing tooling bugs that I encountered while using Rust, and through that I found a real purpose in contributing to Rust.

However, contributions do not have to be only technical. Open source is all about communicating and interacting with other people. You can make a difference simply by advertising what you are doing, for example by sharing your experiences with Rust in a certain domain. One of my contributions was that I have encouraged my schoolmate, @roife, to contribute to Rust, and now they are a regular contributor to Rust Analyzer and became a member of the Rust Project :)

Of course, you should remain constructive and not spam or harass people. Always interact with people responsibly!

Would you like to change something in the Rust Project?

If I had a magic wand, I'd use it to make maintenance and cleanup work get more attention and recognition. I think that we should also highlight the overall "health" of the Rust Project more often.

I believe that more people in the Rust Project should have the opportunity and means to continue doing what they are really good at. I believe in the power of individuals, and we should value that even more in our community. There are so many passionate and talented people working on Rust, and I would like them to see more recognition and more funding.

Would you like to share anything else with the Rust community?

Coding is a social activity, and a means of communication. If we can feel the love that others put into the code that they wrote, and bundle technical parts together with the human parts, then we will be able to achieve something greater in a more harmonious way.

We thank Gen for sharing his thoughts with us, and for all his work on improving Rustup!

That was before uv existed! ↩

1.97.0 pre-release testing

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

The 1.97.0 pre-release is ready for testing. The release is scheduled for July 9. 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-07-07/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.

Inside Rust Blog

Call for testing: Restricting trait implementability and field mutability

What is impl_restriction?

What is mut_restriction?

Restricting construction with struct expressions

How can I help?

Acknowledgements

rust-lang/rust is adopting an LLM policy

Why was this policy created?

Technical products no longer indicate effort

Making code easier to write causes review issues

Mechanically copy-pasting LLM output is a waste of time

So why a policy?

What does the policy say?

General rules

Moderation rules

How does this affect contributors?

Issue reporters

Authors who post LLM-generated code

Reviewers

General review

Review of LLM code

What next?

Funding team progress update — July 2026

Funding total

Gathering details: what we learned

2025 survey results show the need is real

Hashing out the details of the MiR program

General shape: year-long contracts with expectation to renew

How do we decide where to fund a MiR role?

What comes next?

All Hands 2026 retrospective

Sessions

Feedback

All Hands 2027

Infrastructure Team 2026 Q2 Recap and Q3 Plan

Q2 2026 Accomplishments

GitHub Rulesets are now the default protections

GitHub apps are now enabled through team

Shared Renovate Presets

Code security for rust-lang repositories

New GitHub Actions runners powered by external hardware

Experiments with macos-26 on CI

CI dashboard available again

Hardware Security Keys for critical infrastructure access

Partnership with Canonical and Ubuntu Pro for EC2 instances

Faster mergeability checks in Bors

Add the concept of community reviews before PR assignment

Reintroduce delegation approval for merge queue repositories

Continue supporting the moderation team with locking/unlocking of issues

Quality of life improvements in our range-diff viewer for GitHub PRs

Filtering of context-only hunks

Commit messages diff

Warning against Unicode Bidi characters

Small tweaks to the triagebot

Q3 2026 Plans

Finish leftover work from Q2

Improve GitHub Actions security

Move mailing lists from Mailgun to Google Groups to reduce spam

Consolidate logs on Datadog

Reduce reliance on external resources in CI

Stricter networking access rules for crater agents

Start planning for GitHub REST API upgrade

Join us

1.97.1 pre-release testing

Rustup 1.29.1 beta: call for testing!

What's new

How to test

Program management update — June 2026

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

What is `impl_restriction`?

What is `mut_restriction`?