Inside Rust Blog

This Development-cycle in Cargo: 1.94

2026-02-18T00:00:00+00:00

This Development-cycle in Cargo: 1.94

This is a summary of what has been happening around Cargo development for the last 6 weeks which is approximately the merge window for Rust 1.94.

Plugin of the cycle
Implementation
Design discussions
- Workspace and configuration discovery
Misc
Focus areas without progress

Plugin of the cycle

Cargo can't be everything to everyone, if for no other reason than the compatibility guarantees it must uphold. Plugins play an important part of the Cargo ecosystem and we want to celebrate them.

Our plugin for this cycle is cargo-edit which provides commands for editing Cargo.toml files. cargo add and cargo rm have already been merged into cargo. This also provides cargo upgrade for changing version requirements (support in Cargo tracked at #12425) and cargo set-version for changing package.version (no request exists for merging into cargo).

Thanks to kpreid for the suggestion!

Please submit your suggestions for the next post.

Implementation

Build dir layout

Update from 1.93

ranger-ross posted #16502 to update Cargo's internal documentation on the build dir layout. The documentation provided another angle for reviewing this change which led to further refinements like #16514, #16515, and #16519.

For an unrelated change, epage had previously proposed making CARGO_BIN_EXE_* available at runtime, and not just compile time (Zulip) but abandoned it after finding it wasn't needed. After examining the results of the first crater run, they decided to move forward with this to reduce the ecosystem impact of this change and possible offer other benefits and posted #16421.

epage also experimented with running all of Cargo's test suite on the new build dir layout (#16375) which led to #16348.

A new crater run was kicked off and analysis of the results is in going.

Target dir locking

Update from 1.93

In addition to the challenges since the last update, another is that a lock needs to be held while reading the fingerprint to decide if we want to mutate the cache entry or not. Lock upgrading and downgrading has the risk of deadlocking

The last update ended with the idea of the top-level build operation owning all of the locks and them being grabbed exclusively. That can help solve the fingerprint problem, we just grab the lock before reading the fingerprint and we know it is good. This does mean two of the same build will contend for the locks. At least cargo check from rust-analyzer and cargo test (wrapping a cargo build) or cargo clippy won't contend. Except they will in some easy to overlook but significant cases. For cargo check and cargo clippy, cargo clippy only gets unique cache entries for workspace members, so non-workspace members will contend for the locks. For cargo check and cargo test, the cache entries are unique (at least for now, see #3501) except when it comes to proc-macros and build scripts. We decided to punt on this for now to get a minimal design merged that we can iterate on further.

We also punted on dynamic rlimits, Blocking messages for the user, and reusing a build thread with another build unit rather than sitting idle when blocked. At that point, we were able to merge #16155. We are tracking the progress on these deferred items in #4282.

Structured logging

Update from 1.93

weihanglo continued making progress on this, including

refactors (#16485)
documentation (#16476)
adding missing features to cargo report timings (#16414, #16441)
adding cargo report rebuild (#16456, #16408, #16448) to see why rebuilds happens
adding cargo report sessions (#16428) to find the ID needed for use in cargo report timings and cargo report rebuild
providing man pages for cargo report * commands (#16432, #16430)
removing unstable --timings=FMT as it is redundant with cargo report timings (#16420)

On the project goal tracking issue, weihanglo posted a summary, remaining steps towards stabilization, and how people can help.

TOML 1.1

On December 18th, TOML v1.1 spec was released. The major change with this version is that newlines are now allowed inside of inline-tables. The same day, toml v0.9.10 was released to support parsing TOML 1.1 files.

On Zulip, we discussed the transition for Cargo. Users could inadvertently use a TOML v1.1 feature and bump the required version of Cargo to parse their manifest. This is one of many reasons why we encourage those keeping a rust-version to verify it in CI. However, the impact will be limited because cargo package rewrites the published Cargo.toml, including using only TOML v0.5 or earlier features. The impact for this will mostly be felt when using a git patch to the original repo.

There is one caveat in this: toml does not currently preserve whether seconds or nanoseconds in a time were omitted or 0, assuming that seconds is never omitted and that 0 nanoseconds is always omitted. If toml starts to preserve this information and a Cargo.toml field uses a time (likely only in a [*.metadata] field) and the user formats their time using the new syntax, then cargo package will generate a rewritten Cargo.toml that requires a new version of Cargo to parse.

Cargo could detect that a TOML v1.1 feature is used and warn if the package.rust-version field is too old but we didn't view this as blocking because this is the same situation as any other field we have today that you can use that will bump your MSRV.

Cargo support for TOML v1.1 was merged on December 28th (#16415).

`cargo-cargofmt`

There has long been a desire for cargo fmt to also format Cargo.toml files (rustfmt#4091). One major blocker for this work is that the official style guide for Cargo.toml files does not align with existing or expected uses of Cargo.toml files. Proposed ideas for the style guide had been discussed on Zulip but the conversation stalled out.

epage created cargo-cargofmt as a test bed for style guide ideas as well as how to implement them. This included summarizing past conversations as well as comparing existing formatters.

iepathos stepped in and expanded the formatting rules, including some gnarly work to adjust between single and multi-line arrays (cargo-cargofmt#37). Formatting inline tables to multi-line was deferred out as it would likely require a new Style Edition to ensure the package's MSRV is high enough to support it.

See cargo-cargofmt#25 for what is supported today and the issues for what is being considered.

lockfile-path

Update from 1.82

Previously, unstable support for --lockfile-path ../Cargo.lock had been added (#14326). In #15510, we got a request to also support setting it via an environment variable. In discussing this, we felt we should shift the implementation away from a CLI flag to a config field as that would support the environment variables and CLI (through --config). In particular, something we try to keep in mind is how easily someone can look at cargo <cmd> --help and find what they are looking for. The more flags that exist, the more likely it is that a user won't find the flag they are looking for, the less value users get out of all flags as people instead work around what they presume to be the lack of support for a feature. This came up before in the discussion of --out-dir / --artifact-dir (#6100). In weighing the scope of this feature, "hiding" it away in config seems the best course of action.

weihanglo added resolver.lockfile-path in #16510. We'll remove --lockfile-path in another development cycle to allow callers time to transition.

Design discussions

Workspace and configuration discovery

If you accidentally copy a Cargo.toml file to your home directory, it will fail the build of all of your packages without an explicit [workspace]. This is true for any broken or nightly-only Cargo.toml or .cargo/config.toml file that happens to be in a parent directory (e.g. #6646, #6706). For Cargo.toml, Cargo is checking if the current manifest is part of a workspace.

We can at least improve the error message which we are tracking in #6706. It would also help if we discouraged new users from accidentally creating packages in their home directory (#16562).

For the nightly manifest case, Cargo could check if the parent Cargo.toml has a [workspace] table and skip it by delaying the nightly feature check. However, a nightly feature could impact workspace discovery.

For manifests, a workaround is to add an empty [workspace] to your package. However, if you run cargo new in a subdirectory, it will automatically be added as a member. We could extend package.workspace = "<path>" with package.workspace = <bool> for opting in or out of auto-discover of the workspace. For this case, you could insert package.workspace = false to avoid walking ip the directory tree. Cargo script is starting with workspace auto-discovery disabled and this could be how we allow enabling it. This idea is being tracked in #16563.

We would like to more broadly improve the workspace and config discovery behavior which we are tracking in #7871.

Misc

osiewicz sped up cargo clean -p and cargo clean --workspace in #16264.
(Update from 1.93) ranger-ross added unstable support for build scripts to use cargo::metadata without package.links manifest key (#16436)

Focus areas without progress

These are areas of interest for Cargo team members with no reportable progress for this development-cycle.

Project goals in need of owners

Stabilize public/private dependencies
Prototype a new set of Cargo "plumbing" commands
Finish the libtest json output experiment

Ready-to-develop:

Open namespaces
Auto-generate completions
- See clap-rs/clap#3166

Planning:

Disabling of default features
RFC #3416: features metadata
- RFC #3487: visibility (visibility)
- RFC #3486: deprecation
- Unstable features
Pre-RFC: Global, mutually exclusive features
RFC #3553: Cargo SBOM Fragment
OS-native config/cache directories (ie XDG support)

How you can help

If you have ideas for improving cargo, we recommend first checking our backlog and then exploring the idea on Internals.

If there is a particular issue that you are wanting resolved that wasn't discussed here, some steps you can take to help move it along include:

Summarizing the existing conversation (example: Better support for docker layer caching, Change in Cargo.lock policy, MSRV-aware resolver )
Document prior art from other ecosystems so we can build on the work others have done and make something familiar to users, where it makes sense
Document related problems and solutions within Cargo so we see if we are solving to the right layer of abstraction
Building on those posts, propose a solution that takes into account the above information and cargo's compatibility requirements (example)

We are available to help mentor people for S-accepted issues on zulip and you can talk to us in real-time during Contributor Office Hours. If you are looking to help with one of the bigger projects mentioned here and are just starting out, fixing some issues will help familiarize yourself with the process and expectations, making things go more smoothly. If you'd like to tackle something without a mentor, the expectations will be higher on what you'll need to do on your own.

Leadership Council March 2026 Representative Selections

2026-02-13T00:00:00+00:00

The selection process for representatives on the Leadership Council is starting today.

Every six months, half of the council terms end. The following teams are up to choose their representative for the next year:

Compiler
Devtools
Launching Pad

We are aiming to have the teams confirm their choices by March 20, 2026, and for any possible new members to be ready to join the council meetings starting March 27th.

Criteria for representatives

Any member of the top-level team or a member of any of their subteams is eligible to be the representative. See candidate criteria for a description of what makes a good representative.

There is a limit of at most two people affiliated with the same company or other legal entity being on the council ¹. During the selection process, the council will consider the affiliation of candidates to decide if all choices will be compatible with that constraint.

Representatives may serve multiple terms if the team decides to choose the same representative again. There is a soft limit of three terms.² It is recommended that teams rotate their representatives if possible to help avoid burnout and to spread the experience to a broader group of people.

What do Representatives do?

A representative provides a voice on the council to represent the interests of their teams and contribute to the long-term success of the Rust Project. A detailed description of the role may be found at the Representative Role Description.

How should teams make their selection?

The Leadership Council has put together a Representative Selection Guide with recommendations for teams on how to go about choosing a representative. It is not a requirement that teams follow this guide; top-level teams may choose their own process.

See Limits on representatives from a single company/entity ↩
See Term limits. ↩

Program management update — January 2026

2026-02-11T00:00:00+00:00

Happy 2026! We got off to a great start with Project goals and hiring. I had a couple of weeks off in December, and that was really lovely.

Project goals

The goals initiative is in full swing. Following the call for proposals, people started opening pull requests for new goals. In addition, many of the current goals are planned to continue into 2026.

As of right now, we have around 60 goals proposed, with a few more to come. That's a lot! But we're moving to the second phase.

In February, we're inviting feedback on the proposed goals -- particularly from the teams being asked for something. You can look at the Goals by team page, find your team, and see all goals that call it out. It's a good time to check whether these goals make sense to you, start thinking about your capacity, and consider whether you have champions who can sign up.

In March, we'll open the RFC for 2026 goals, which all the team leads will review. They'll look at the proposed goals in aggregate and sign off on the champions and team capacity.

And then from April to December, it's implementation season!

2026 changes

In addition to running the program throughout the whole year, we've made other changes.

Flagship themes gave way to Roadmaps. Many of the larger initiatives we want to achieve don't really match the six-month or even yearly cycle. We want goals to be achievable in a single year, but e.g., completing the async features and ergonomics will likely take multiple years to complete.

A goal can belong to more than one roadmap.

Above roadmaps are Application areas such as "Cross-language interop" or "Safety-critical & regulated" -- large initiatives that often align with a specific industry. We are hoping that the roadmaps and application areas can help focus industry funding. For example, an automotive company may be very interested in funding the "Safety-critical" area, as the code and libraries they use need to go through expensive attestation. On the other hand, companies with large C++ codebases will be more interested in "Cross-language interop".

There are also individual goals that we want to highlight because we think people will be excited about them and we expect them to stabilize this year (note that the current list is likely to change while we look at all the proposed goals).

Getting all this in was a significant effort by Niko Matsakis, Rémy (lqd), and myself. I'd like to thank everyone for their submissions and for participating in the discussion!

Hiring a second Program Manager

Originally, the Leadership Council planned to hire two Program Managers so there would be continuity, a backup, and enough capacity to cover the Project's needs. Unfortunately, in 2025, it hadn't been clear whether there would be enough budget to support two people, so the Council had opted to hire just one.

After getting the 2026 funding from the Foundation clarified, the Council allocated extra funds to hire a second Program Manager. This let us reach out to Nurzhan Saken, whom we'd hoped to bring on board along with yours truly back in June.

I spoke to Nurzhan, saw why TC and Joel Marcey wanted to hire him in the first place, and I'm delighted to announce that Nurzhan joined the Project at the beginning of February!

I'll help him get on board, and I'm really excited about this.

Rust for Linux

We've continued our regular meetings, and you can see the updates on the Rust for Linux project goal tracking issue.

Some highlights:

We now have a wiki that covers Field Projection, In-place initialization, and the other language features that we're planning to build.
Ding Xiang Fei opened a 2026 Project goal for Supertrait auto impl.
Gary Guo opened a pull request implementing the Pass pointers to const in assembly RFC#3848.

I've opened a pull request that proposes a new Rust for Linux roadmap which ties in the existing standalone goals (Field projections, In-place initialization, and Supertrait auto impl) and breaks down the original language features into individual goals as well.

This way, we can track everything for Rust for Linux under a single roadmap item and also have smaller, more focused, and easier-to-review goals.

CPython collaboration

We continued our weekly meetings with the Python folks interested in bringing Rust into CPython (the canonical Python interpreter, written in C). We have representatives from the Compiler, Cargo, Libs-API, and Language teams there, and we bring in additional experts where it makes sense.

Here are some of the topics we went through:

Bootstrapping Rust currently relies on a Python script (bootstrap.py). If Python starts depending on Rust at some point, we'll have a cycle we'll need to sort out.
Safely modeling Python objects that are attached/detached from Python threads within Rust. This is something PyO3 deals with, but the API is clunky, and there are soundness edge cases there. We discussed language features that could help here.
Building/linking the Rust standard library to Python extension modules in a way that doesn't expose symbols that could conflict.
Setting different linker arguments for bin and lib targets when both are present in a single crate.
Potential interoperability between async Rust and Python's asyncio.
Introducing Rust into large C codebases -- the technical as well as social aspects. For this, I reached out to the Rust for Linux folks, and Miguel Ojeda shared his perspective on introducing Rust into the Linux kernel.

Please note, this is all a preliminary discussion. Even the idea of adding Rust to CPython has not yet been proposed formally. One of the outcomes of the work here is a Python Enhancement Proposal (PEP) (analogue to Rust RFCs) that does so.

cargo-script

This is one of my most anticipated features. Cargo script lets you take a single Rust file, specify any dependencies, and run it. You can think of it as a much more streamlined cargo run where you don't have to set up a whole directory structure with Cargo.toml and so on.

In its simplest form, you can do:

#!/usr/bin/env cargo

fn main() {
    println!("Hello, world!");
}

(until it's stabilized, the actual shebang invocation is something like: #!/usr/bin/env -S cargo +nightly -Zscript)

And run it either with cargo hello-world.rs or (if you mark the file as executable): ./hello-world.rs:

$ ./hello-world.rs
warning: `package.edition` is unspecified, defaulting to `2024`
   Compiling hello-world v0.0.0 (/home/example/tmp/hello-world.rs)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `/home/example/.cargo/build/23/c81d708245acde/target/debug/hello-world`
Hello, world!

Cargo will build the source and run the compiled binary.

This gets really powerful when you start including dependencies -- cargo script is able to parse a "front matter" section which is a subset of Cargo.toml:

#!/usr/bin/env cargo
---cargo
package.edition = "2024"
[dependencies]
chrono = "0.4"
---

fn main() {
    use chrono::Datelike;

    let now = chrono::Local::now();
    let days_in_month = now.num_days_in_month();
    let last_day = now.with_day(days_in_month.into()).unwrap().date();

    println!("This month has {days_in_month} days and the last day is: {last_day}");
}

And have it download and compile the dependencies and run the resulting script:

$ ./hello-world.rs
    Updating crates.io index
     Locking 31 packages to latest Rust 1.93.0-nightly compatible versions
      Adding android_system_properties v0.1.5
      Adding autocfg v1.5.0
   [...]
   Compiling num-traits v0.2.19
   Compiling chrono v0.4.43
   Compiling hello-world v0.0.0 (/home/example/tmp/hello-world.rs)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
     Running `/home/example/.cargo/build/23/c81d708245acde/target/debug/hello-world`
This month has 28 days and the last day is: 2026-02-28+01:00

In addition to writing "scripts", cargo script is fantastic for coming up with minimal bug reproducers and quick prototypes. The overhead of a few directories and an extra file doesn't seem like that much, but in practice, having a single file you can share or just include in a Markdown code block makes a huge difference.

This feature, in various iterations, has existed for years, but now (thanks to Ed Page's determination) it is tantalizingly close to shipping on stable.

Getting the front matter stabilized required working with the Style team to settle on all the formatting specifics and then implementing them. Once the Style team thought it was all set, I checked with Ed and learned that while everything was good there, the front matter stabilization seemed stuck on the language side.

Early in December, the Lang team had a concern about stray carriage-return (CR, /r) characters causing confusion: they could be rendered as new lines, but the Rust tooling would not interpret them as such. Ed opened a PR a few days later, which sat there for weeks without comment.

I brought this up with Josh Triplett, and we invited Ed to a Lang meeting where the team discussed this, clarified the request and the reasoning behind it, and agreed on the next steps. Ed made the requested changes, and the front matter stabilization has passed the final comment period (FCP) a few days ago.

The cargo script stabilization issue is now in FCP as well, with no concerns listed.

I'm extremely excited about this.

Crates.io mirroring and verification

While there is support for alternative registries, crates.io is what most users (and tooling, e.g., CI) interact with when downloading crates. This can put too much pressure on crates.io, and some people can't rely on it (for example, because they don't have enough bandwidth, a reliable internet connection, or firewalls preventing access).

Linux package registries have, of course, dealt with this as well, and most popular distros have package mirrors, so you rarely even hit the original source. These can be closer to you and may often back internal CI in companies.

One concern with mirrors -- especially with the security of the supply chain finally being taken more seriously -- is making sure they serve the same content as crates.io would: that there's no tampering either on the mirror's side or during transit.

Walter Pearce and Josh Triplett are driving an effort to build such a verification system building on The Update Framework (TUF), and last year, we had a Project goal tracking this work.

This was moving forward, but aside from a few meetings, there was not a lot of external communication. This was frustrating for people who were following the work and wanted to build on top of it. This effort is also sponsored by the Foundation, and while they produce regular reports, they're not frequent or detailed enough for the needs of the Rust ecosystem.

I set up a meeting with a group of people interested in this work, and they clarified their expectations and came to an agreement. Here's what came out of it:

We'll open a 2026 goal for this effort.
Walter will be the point of contact, and he'll be sending regular updates.
I've set up a fortnightly sync meeting with the interested people.
The Program Managers (Nurzhan and/or I) will attend, take minutes, and make sure the updates are posted.

There's great work being done here, but we all need to work towards making it visible.

Worth a look

Rust Foundation posts

Announcing the RustConf 2026 Program Committee
How We Invested in Rust in 2025 — and What Comes Next
Rust Foundation Member Announcement: Meilisearch & Doulos
Rust at Scale: What WhatsApp’s Security Journey Tells Us About the Future of Safer Software

Rust blog posts

This Development-cycle in Cargo: 1.93
What is maintenance, anyway?
Infrastructure Team 2025 Q4 Recap and Q1 2026 Plan
What does it take to ship Rust in safety-critical?
crates.io: development update
Announcing Rust 1.93.0
2025 Rust Foundation Annual Report Project Director Update
First look at 2026 Project goals
January 2026 Project Director Update

Stats

Total words of meeting minutes written: 323k (June–January)

Meetings attended: 40

Total words of meeting minutes written (January): 57.8k

Average (mean) word count per team meeting:

Cargo: 1.9k
Lang triage: 6.7k
Libs-API: 6.9k
Leadership Council: 3.2k

January 2026 Project Director Update

2026-02-09T00:00:00+00:00

New year, new Foundation Board Meeting recaps! Yes, it is February now, but this is the update we meant to post in January covering the Rust Foundation board meeting that happened on December 9, 2025. Read the full minutes on the Foundation's site. Highlights include:

The Foundation staff proposed the final strategic goals for 2026-2028 and the board approved. Check out the full strategy!
Requests to crates.io served by CloudFront are using up AWS-donated credits at a higher rate than expected; the Foundation is working on short- and long-term ways to address this.
The Foundation's engineers recent progress includes:
- GitLab support for Trusted Publishing is now in public beta
- The Capslock capability analyzer has a functioning prototype
- Crates.io's vulnerability scanning RFC is in final comment period
- More analytics now being tracked on crates.io enables identifying anomalies in traffic
The RustConf visa letter request page, sponsorship prospectus, and CFP are now all live. This is much earlier in relation to the conference than previous years, allowing more time for travel planning.
The training program initiative proposed launching a Foundation accreditation program for companies providing Rust training, even though the individual training course has not yet launched. While the initiative will continue to explore future options for an individual training course and certification portion, accreditation for existing Rust training providers is the priority for the foreseeable future. The board approved.
The Board discussed and approved of the Foundation's 2026 budget.

We'll be back soon with February's real update!

First look at 2026 Project goals

2026-02-03T00:00:00+00:00

Hi all,

This is an update on the Project goals plan.

We want your feedback!

We have just published the first draft of the Project goals RFC. This first draft contains the goals proposed thus far as well as candidate flagship themes.

As a first draft, the purpose of this document is to solicit feedback and spark discussion -- so please, take a look! If you have questions or comments, open up a topic in the #project-goals/2026-workshop channel.

Questions

Here are some of the questions I would like people's input on (these questions link to questions in the FAQ that give more details):

Do you have concerns about any goals that ask support from one of your teams?
- E.g., you think this goal is a bad idea, or you think that your team does not have capacity to support the goal.
Are the "Team Asks" in these goals appropriate?
- In particular, should they be larger?
What do you think of the flagship themes, do they make sense to you?
- Do you have alternative ideas for flagship themes? You can propose your own.
- Would you be interested in serving as a point of contact for one of those themes, helping the goals program to draft periodic updates and track overall progress?
Is there work that you would like to do that you think would make a good goal or fit well with the themes?
- (If you're blocked on funding, we may be able to help!)

Frequently asked questions

Why are you saying 2026 goals and not 2026H1 goals?

We're shifting the process from something we do every 6 months to something we do once a year. The goal program is focused on larger, long-running goals that will take significant work during the year.

Team members can add new goals later in the year but you must already have a champion and general agreement from the team that this is a goal they like.

What is the process timeline?

In each case the task begins at the start of the month and then extends throughout the month:

January: Solicit goal proposals and write up first draft.
February: Solicit feedback and prepare RFC.
March: Open RFC and get it merged.
- The RFC must be approved by the leads of every team that has a "team ask" listed in any goal.
April: Announce 2026 Project goals.

What if I have a goal I would like to propose? Is it too late?

No, it's not too late. We accept goal proposals throughout the year, but we require goals coming later in the year (including February) to already have a champion and buy-in from the team. (Of course, as a team member, you can champion your own goal within your team).

I'd like to propose a goal, but I would need funding to work on it. Is there funding available for Project goals?

Yes! We are discussing with possible sponsors both of Project goals and of champions of Project goals. Please reach out to nikomatsakis to discuss.

What is a "Flagship Theme"?

The idea of a flagship theme is that, for people paying only limited attention to the Rust Project, it should help them get a high-level view of the "big things" that they can expect from the Project. These stretch somewhat past a year, many of them (e.g., "Beyond the &") represent multi-year technical programs.

The current set of flagship themes was decided by reading over the goals and looking for the trends that we saw. However, I would like to get to the point where every flagship theme has a point of contact that is holding the vision, fielding questions, and helping to draft updates for periodic blog posts on overall progress.

Can I propose a new flagship theme?

Yes! But please do so by Feb 14 (Valentine's Day). If you'd like to propose a new flagship theme, you can open a PR using the FLAGSHIP_TEMPLATE.md.

If you'd like to propose changes to a flagship theme, or would consider acting as a point-of-contact for a theme, reach out on #project-goals/2026-workshop.

I see a "small|medium|large" ask of my team, what does that mean?

In brief:

Vibes: Quick check if your idea is worth exploring and bringing a more mature version to the team in the future.
Small: Routine small reviews and actions by the team.
- --> This is typically appropriate for a task that will require a single PR, like adding a lint.
Medium: Exploring a design or feature with dedicated support from a team member and involving the rest of the team in a vibe-check and small way.
- --> This is typically appropriate for an experiment or something early stage or a task that will require multiple PRs to complete.
Large: Reaching consensus within the team about a design or feature.
- --> This is typically appropriate for RFCs, stabilizations, or other things that require broad team consensus.

Can you give me some examples of what small|medium|large means?

Here are some rules of thumb and historic examples, focusing on lang + compiler:

Task	Lang	Compiler
Adding a lint	Small	Small
Landing a complex compiler change	-	Medium
Driving an early stage lang experiment	Medium	Medium
Accepting a lang RFC	Large	Medium
Stabilizing a lang feature	Large	Medium
Vet and stabilize subtle reference changes	Large	-
Overhaul compiler's incremental system	-	Large

We'll have to figure out what these levels mean for other teams!

The idea of the levels to help us avoid overcommitting:

Team should expect to only take a small number of large items, quite possibly zero, depending on how much bandwidth they have.
No individual should champion more than a small number of goals.

What is a team champion?

A team champion is someone who agrees to support the goal owner on an individual basis. Champions should expect to meet with the goal owner on a weekly or biweekly basis.

Champions often help provide design guidance and advise on who within the team the owner ought to talk to for more information. They should also be prepared to field questions from the rest of the team about the goal.

Can I champion my own goal?

If you are a member of the team in question, you can champion your own goal, sure.

Why do you call these Project goals if some of them originate from outside the Project?

A Project goal is an agreement between...

an owner, who will be doing the work;
and a team, who will be accepting the work.

Owners may or may not be members of a Rust team.

We only accept goals where there are both owner(s) to do the work and team(s) that want it.

The fact that the team(s) agree to the goal is what makes it a Rust Project goal.

2025 Rust Foundation Annual Report Project Director Update

2026-01-27T00:00:00+00:00

The Rust Foundation has published two documents today, addressing what their funding supported in 2025 and their 2026-2028 strategic plan.

The 2025 Annual Report details the Foundation's finances and how the Foundation supported the Project last year. For the people behind the finances and all the work they've done, see the Foundation's 2025 Year In Review, which you may have seen in December.

Looking forward to the next 3 years, the Foundation staff worked with the Leadership Council, Project Directors, and surveyed the Project as a whole to inform their Strategic Goals for 2026-2028. The 5 areas the Foundation will be concentrating on are:

Stable, secure infrastructure
Sustainable support for maintainers
Responsible growth in adoption
Meaningful engagement from organizations that rely on Rust
Building and supporting strong, connected global communities

View the Rust Foundation's full strategic plan for more details, examples, and goals.

We look forward to working with the Foundation towards these goals over the next 3 years!

Infrastructure Team 2025 Q4 Recap and Q1 2026 Plan

2026-01-13T00:00:00+00:00

As we close out the fourth quarter of 2025 and step into 2026, here’s what the Infrastructure Team delivered and what we’re focusing on next.

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

Q4 2025 Accomplishments

More settings configured in the `team` repo

The Infrastructure Team always tries to move manually configured settings into Infrastructure as Code (IaC). IaC has various benefits:

It helps teams self-serve, since they can inspect their configuration even without admin privileges and request changes via pull requests.
It improves security by making configuration drift harder. Manual changes are still possible, but they will be detected more easily and reverted on the next run of the IaC automation.

GitHub environments

All GitHub environments for Rust Project repositories are now defined in the team repo.

Here's an example from the bors repository file:

[environments.production]
branches = ["main"]

[environments.staging]
branches = ["main"]

Thanks to amustaque97 for his great work on the GitHub environments issue!

Trusted publishing

All crates owned by the Rust Project that use crates.io trusted publishing now configure it as IaC via the team repo.

Here's an example from the measureme repository file:

[[crates-io]]
crates = ["analyzeme", "decodeme", "measureme"]
publish-workflow = "publish.yml"
publish-environment = "publish"

The work to configure trusted publishing for all the Rust Project crates will be easier now.

Crates.io index and docs.rs served via Fastly

The crates.io index and the docs.rs website are now served by the Fastly CDN.

We made this change because Fastly donates its CDN to us, and we want to use our AWS credits for other resources.

For docs.rs, we also enabled Fastly shielding, which adds an additional caching layer to reduce the load on our origin server. Here's the effect of enabling shielding on the number of active connections after a brief experiment on December 2 and enabling it permanently on December 3:

Note that the crates.io index is still partially served by CloudFront, and we can configure how much traffic goes to each CDN.

Thanks to the crates.io and docs.rs teams for helping with this!

The new Bors is used to merge Rust compiler pull requests

The Infra and Bors teams continued working on migrating the Rust CI from the legacy Bors (Homu) to the new Bors, written in Rust.

We have now enabled the new bot to merge rust-lang/rust PRs, completing the migration off Homu and improving the reliability of our continuous integration infrastructure 🎉.

We would like to thank all contributors who contributed to the development of bors, in particular Võ Hoàng Long and Sakibul Islam.

rustc-perf benchmarks are now executed in parallel

We made progress with the Project Goal for parallel benchmarking of the Rust compiler. We now have two x64 machines that run benchmarks in parallel, which reduced the latency of getting a full compiler benchmark result from ~1h 20m to ~40m.

In 2026, we plan to make further improvements to the benchmarking suite, such as enabling benchmarking on other hardware architectures.

Repository default branch renames

The following repositories have renamed their default branch from master to main:

annotate-snippets-rs
ar_archive_writer
cmake-rs
compiler-builtins
docs.rs
infra-team
moderation-team
rust
rustfmt
rustup
rustwide
stdarch
team
this-week-in-rust

Hired a new teammate

The Rust Foundation hired a new Infrastructure Engineer in Q4. They’ll start in January 2026, increasing the team’s capacity to better serve the Project.

Thanks to Kobzol for helping with the hiring process!

Triagebot enhancements

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

We implemented several notable changes in Q4 2025.

Triagebot label command now supports aliases

We now have a mechanism for creating aliases when applying batches of labels to an issue (or a pull request) on GitHub. If you find yourself repeatedly applying or removing the same set of labels, you can now create an alias.

Example:

@rustbot label +regression-untriaged +I-prioritize +needs-repro

could become an alias:

@rustbot label regression-needs-triaging

Thanks to @apiraino for implementing the feature in #2216 (documentation).

Turn automatic backport nominations into suggestions

We now offer project teams a streamlined workflow for backports to the stable/beta release channels. Patches fixing regressions can be manually "nominated" for backport by anyone interested in having said patch tested earlier. Backport nominations are discussed during the weekly triage team meetings (and then approved or declined).

Now teams can configure the triagebot to:

Automatically nominate patches fixing P-high/P-critical regressions occurred in the beta/stable release channels.
Automatically open topics in our Zulip chat to evaluate backports asynchronously (see the compiler and rustdoc channels). During the triage meeting, the topic is quickly skimmed and a decision can be taken faster.

Thanks to @apiraino for implementing the feature in #2191 (documentation).

New Triagebot commands: `r? me` and `@rustbot reroll`

Two new triagebot features have been added to improve reviewer assignment.

First, @Urgau implemented support for using r? me as a shorthand for self-assignment in #2218. This provides a convenient alternative to manually typing r? @username when assigning a pull request to yourself.

Second, @Kobzol added the new @rustbot reroll command in #2219. This new command re-runs the automatic reviewer assignment logic normally triggered when a PR is first opened, using the latest diff and owner map.

`[no-mentions]` handler removed from Triagebot

We have removed the [no-mentions] handler from triagebot, as it is no longer needed. This handler was originally used to ask users to avoid @-mentions in commit messages to avoid triggering user notifications.

Thanks to GitHub’s recent change, which disables notifications for mentions in commits, this workaround is no longer necessary. We appreciate GitHub for making this improvement and simplifying the workflow for everyone involved.

Highlighting of log lines in Triagebot’s GHA log viewer

Triagebot’s GitHub Actions log viewer now supports highlighting selected log lines, similar to GitHub’s own code highlighting feature.

This improvement was implemented by @Urgau in #2234. It allows users to select one or more lines in build logs and share them easily using highlighted URLs, making it simpler to point others directly to relevant sections of long logs.

Here’s an example of the new functionality in action:

Triagebot `[mentions]` now supports glob patterns

The [mentions] configuration in triagebot now supports glob pattern matching.

This improvement was implemented by @Urgau in #2244. With this change, it’s now possible to group related paths under a single rule.

For example, it is now possible to write:

[mentions."library/{dec2flt,flt2dec}"]
cc = ["@ghost"]

instead of maintaining two separate entries for each directory.

Internal Sites team takes its first action

The new t-internal-sites team, responsible for maintaining and supporting the Rust project’s internal websites such as the Forge and the RFCs site, has taken its first action.

The team began by addressing stale non-RFC pull requests which had been stale due to the lack of ownership before t-internal-sites introduction.

Q1 2026 Plans

Finish Q4 2025 goals

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

docs.rs infrastructure modernization: Although we made various improvements to docs.rs in Q4 2025, such as improving the CDN setup, 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.
GCP Dev Desktops: spin up one or two dev desktops in GCP.

You can read more about these goals in our Q4 2025 plan.

Account and Access Management

Finish the work started in rust-lang/infra-team#64 by setting up a Google Workspace for the Rust Project for automated account and access management using SAML.

Move to GitHub Rulesets

To have more flexibility and configurability, we want to migrate from branch protection rules to GitHub Rulesets across all Rust Project repositories.

The branch protection rules are already defined as code in the team repo, so we will need to update the IaC automation to create rulesets instead of branch protection rules.

This would also allow us to configure merge queues as IaC, which is currently not possible (see rust-lang/team#1735).

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!

What is maintenance, anyway?

2026-01-12T00:00:00+00:00

Recently, the Rust Foundation has announced the Rust Foundation Maintainer Fund, whose goal is to support Rust Project maintainers. We are currently cooperating with the Foundation to define the guidelines of this Fund, such as what kind of work to fund, how to select maintainers to fund and others. One of the questions that keeps coming up is this: Who exactly is a maintainer, and what work can be considered as being maintenance? This post provides some observations that might help answer these questions.

Wikipedia defines software maintenance as "modification of software after delivery", but that does not correspond very well to how maintenance works in open-source or in Rust. There is no single delivery of Rust after which it would switch to "maintenance mode"; we deliver a new nightly version of Rust every day, and a new stable version every six weeks. And if someone contributes a pull request to the compiler, they clearly modify it, but as much as we treasure contributions to Rust, that does not immediately make them a maintainer. Instead, let us try to describe how we understand maintenance in the Rust Project.

Keeping the lights on

We could interpret the word "maintain" literally, in the sense of keeping something in a specific (hopefully working) state over a long time period. And that is indeed a large part of what maintainers do: they ensure that things that work today will still continue working tomorrow. There are many ways in which a software project might stop working properly, so this work is naturally very diverse. It includes activities such as issue triaging, investigating and fixing bugs, dealing with CI failures, responding to security incidents, resolving performance regressions, updating dependencies, making sure that documentation is up to date, and many others.

This kind of "janitorial" work is quite challenging for several reasons:

It can be difficult to demonstrate the positive effects of this work on a given software project. Users sometimes assume that if something works now, it will keep working indefinitely. Furthermore, Rust has a very high bar for being reliable (in many aspects of that word), so people are used to the fact that the compiler works correctly, that critical bugs are resolved as quickly as possible, that new releases are published every six weeks, etc. But all that takes considerable effort, even without considering shipping any new features. Therefore, a successful report of maintenance work can be simply "things still work as they used to", and consistent maintenance over time manifests as an absence of noteworthy incidents.
It can be very unpredictable, because it is hard to estimate in advance what things will break next. This also makes it difficult to plan this work ahead and make promises about what kind of work will get done in a given time period.
Finding motivation for performing a lot of maintenance work can be a struggle. It is often not work that someone wants to do, but work that has to be done. That can be draining, especially if that work is done by volunteers.
Maintenance is often not on a roadmap, and often not viewed as high-status work that gets someone recognized or promoted.

Enabling evolution

The maintenance activities described above are required to keep a software project working. However, usually that's not all we need. Most software projects need to evolve over time, and Rust is no exception; this usually means adding new features and making improvements. Improving the language, compiler, standard library, tooling, etc. might unblock some Rust users, which is great. But what might not be so obvious is that we often need to unblock the contributors who implement these new features in the first place!

Before someone even starts to implement a new feature, they often want to get a vibe check from someone else knowledgeable with the corresponding part of the codebase, or advice on how best to approach the implementation. Furthermore, certain features require complex refactorings to be performed before they can be implemented. Then, once a pull request with a new feature is submitted, someone has to review it. And even once a pull request lands, it may introduce new technical debt, which will eventually need cleaning up.

However, it's not only refactoring and code reviews that help make progress on various improvements. Even implementing a new feature can unblock many other contributors, who might want to add other features that depend on it.

And all of that is another part of what maintainers do. They continuously improve the codebase so that it is easier to land new changes, they review pull requests, and they communicate with and mentor other contributors. This work is crucial to ensure the long-term health of constantly evolving codebases. And it also has a strong second-order effect. By unblocking other Rust contributors, new features and improvements can be landed quicker and more frequently, which in turns unblocks and improves the lives of Rust users, which results in a positive feedback cycle. This is a multiplicative effect that strongly benefits everyone!

This enablement work of course requires having a deep knowledge of the codebase, but also a long-term focus to perform complex refactorings and grit to continuously review tons of pull requests.

Conclusion

Based on the observations presented above, we could say that a maintainer is someone who continuously ensures that a software project keeps working, but who also does a lot of hard (and often invisible) work to enable other contributors to evolve and improve the project.

These are some examples of the kinds of things we see as needing additional support, including from efforts like the proposed Rust Foundation Maintainers' Fund. We see the work of maintainers as work that has a multiplicative effect on the Rust Project. We have an interest in supporting other types of work with a similar multiplicative effect.

You probably already guessed that maintenance work is not easy, and maybe that is one of the reasons why there seems to be a perpetual imbalance. There are often many people who want to contribute to open source, by making improvements and implementing new features, as it is often seen as being fun, and implementing a new feature is also a very visible achievement that may help meet someone's needs or give them something obvious to be proud of. But there are far fewer people who want to continuously maintain a codebase (especially if they are not paid for it!), as the results of good maintenance are much more difficult to demonstrate, and it often more closely resembles work rather than pure fun.

While being a maintainer can be challenging, becoming one is even more difficult. It is not really possible to become a maintainer overnight, as it takes time to not only gain deep expertise in parts of a codebase, but also to gain trust of other maintainers and contributors. All while regularly doing work that many others aren't enthusiastic about doing.

We are incredibly happy that we have so many awesome maintainers in the Rust Project, who pour their souls into ensuring that Rust becomes better every day, and who invest enormous amounts of time into becoming experts in certain Rust projects so that they can effectively maintain them. However, many of those maintainers are volunteers, and when so much maintenance burden falls on someone who still has to work another job to pay the bills, it can lead to burnout. This is something that we want to prevent.

People who do open-source maintenance deserve to be supported and rewarded for it, which is where maintainer funding comes in. We are currently seeking mechanisms for supporting people who maintain various Rust Project codebases, in a way that provides stability and enables them to focus on what they do best: improving Rust. We also want to publicize their great work—which is otherwise often near-invisible—both to give them something to be proud of, and to attract more support and funding for this critical work. With the Rust Foundation Maintainer Fund and other similar initiatives, we hope to improve the long-term sustainability of Rust maintainership. Stay tuned for more updates.

This Development-cycle in Cargo: 1.93

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

This Development-cycle in Cargo: 1.93

This is a summary of what has been happening around Cargo development for the last 6 weeks which is approximately the merge window for Rust 1.93.

Plugin of the cycle
Implementation
Misc
Focus areas without progress

Plugin of the cycle

Cargo can't be everything to everyone, if for no other reason than the compatibility guarantees it must uphold. Plugins play an important part of the Cargo ecosystem and we want to celebrate them.

Our plugin for this cycle is cargo-override which helps manage your patch table.

Thanks to eopb for the suggestion!

Please submit your suggestions for the next post.

Implementation

Rendering diagnostics

Update from 1.92

jneem continued the work of migrating to annotate-snippets in #16143. This effort is being tracked in #15944.

A compiler major change proposal (or MCP) was posted to switch nightly rustc over to using annotate-snippets (compiler-team#937). That experiment went well enough that it has now been approved for general use by rustc (compiler-team#947). The relevance to Cargo is that this lowers the barrier for enabling the unicode renderer for all diagnostics. Muscraft started this off by adding to Cargo -Zrustc-unicode (#16243).

Before:

warning: used import from `std` instead of `core`
  --> src/error.rs:25:5
   |
25 | use std::num::NonZeroUsize;
   |     ^^^ help: consider importing the item from `core`: `core`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.92.0/index.html#std_instead_of
_core
note: the lint level is defined here
  --> src/lib.rs:53:9
   |
53 | #![warn(clippy::std_instead_of_core)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

After:

warning: used import from `std` instead of `core`
   ╭▸ src/error.rs:25:5
   │
25 │ use std::num::NonZeroUsize;
   │     ━━━ help: consider importing the item from `core`: `core`
   │
   ╰ help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#std_instead_of_core
note: the lint level is defined here
   ╭▸ src/lib.rs:53:9
   │
53 │ #![warn(clippy::std_instead_of_core)]
   ╰╴        ━━━━━━━━━━━━━━━━━━━━━━━━━━━

You can enable this selectively for nightly by adding it to your ~/.cargo/config.toml file:

[unstable]
rustc-unicode = true

Stabilization is being tracked in rust#148607

Improving diagnostics

Update from 1.92

We wanted to give thanks to all the people who helped improve the quality of Cargo's error messages:

0xPoe (#16125)
Amberley-Sz (#16241)
epage (#16216, #16225, #16227, #16233, #16256)
motorailgun (#16207, #16268)
TanmayArya-1p (#16338)

Linting

Update from 1.90

weihanglo added the lint implicit_minimum_version_req (#16321), improving the linting system along the way ( #16320, #16324, #16364 ).

Something that came up in #16321 is whether we should lint dependencies in workspace.dependencies or on every time that one of those is inherited.

Or put another way, given ./Cargo.toml:

[workspace]
members = ["a"]

[workspace.dependencies]
clap = "4"

and ./a/Cargo.toml:

[package]
name = "a"

[dependencies]
clap.workspace = true

Should you see the following each time you inherit a dependency:

[WARNING] dependency version requirement lacks full precision
 --> Cargo.toml:7:7
  |
7 | dep = "1"
  |       ^^^
  |
[NOTE] dependency `dep` was inherited
 --> a/Cargo.toml:8:5
  |
8 | dep.workspace = true
  |     ----------------
  = [NOTE] `cargo::imprecise_version_requirements` is set to `warn` in `[lints]`

Or see the following only once, regardless of whether you inherit:

[WARNING] dependency version requirement without an explicit minimum version
 --> Cargo.toml:7:7
  |
7 | dep = "1"
  |       ^^^ missing full version components
  |
  = [NOTE] `cargo::implicit_minimum_version_req` is set to `warn` in `[lints]`

To liken this to Rust code, should we treat inherited dependency sources as macros, injecting their content into the caller, or like functions which act in isolation. Macros emit lints for each invocation and are subject to the caller's lint level. Functions emit lints only for where they are defined, not used, and have their own lint level controlling them.

When linting workspace.dependencies, what controls the lint level? We already have the need for "workspace lints" for linting virtual workspaces (e.g. #13723) and the dependency tree (e.g. #9930), so this problem isn't unique. The current thought is we'd use workspace.lints not just for inheriting lints for for controlling workspace lints. We may need to do a fallback to lints for implicit workspaces, like we do for package.resolver.

Another problem is what edition is applicable? In a previous issue with dependency inheritance, we framed the problem around the act of inheriting and put the responsibility on the package. That worked well for that case but won't work for all of these other cases. We have talked for a while of a need for a workspace edition. Luckily, we can punt on this until we need to make a change across editions.

In the end, we decided to lint the workspace.dependencies entry though we have flexibility to change this in the future, especially with this feature being unstable.

In response, weihanglo posted #16367 to update the unknown_lints lint to match what we did for implicit_minimum_version_req.

Turn all warnings into errors

Update from 1.81

jyn514 posted on Zulip looking at updating the Rust bootstrap process to not require a full rebuild when denying or allowing warnings. The unstable build.warnings seemed like a perfect fit.

When jyn514 tried to apply this to bootstrap in #148332, they ran into problems with hard warnings (#14802-comment). In the end, we decided to ignore hard warnings which epage addressed in #16213.

jyn514 also pointed out on Zulip that this does not abort the build after the first package with warnings, unlike RUSTFLAGS=-Dwarnings. epage suggested have it key off of --keep-going for whether it should error after the first set of warnings or show all warnings. This was not discussed further.

Shell completions

Update from 1.83

We'd like to thank the people who helped move forward our new auto completion system (#14520):

charmitro (#16322)
epage (#16327, #16296)
jakobhellermann (#16210, #16215)

Build dir layout

Update from 1.92

epage proposed a transition plan on #15010 with the current focus being on testing, including:

crater (rust#149852)
cargo's test suite (#16375)
manual testing

This led to several fixes ( #16300, #16335, #16348, ).

epage also did an audit of the feature for any potential changes that could impact testing. This led to:

Slipping in more layout changes (#16351, #16345)
Finalizing the names of the directories on Zulip
Double checking any other open questions

Next will be working through the test results and opening this up for wider testing by doing a Call for Testing.

Custom final artifacts

While the build-dir layout is an implementation detail, there are legitimate reasons for relying on it and it would help with future transitions to provide solutions for people who are relying on it today.

One such use case is accessing final artifacts created by build scripts (#13663). In considering this, we need to keep in mind that:

there is the potential for any build script in the dependency tree to create such an artifact
Cargo tries to avoid collisions in intermediate and final artifacts, see also #6313
Cargo tries to be safe under concurrent access between multiple cargo invocations and between multiple build scripts within a single cargo invocation.

Cargo can't just provide build scripts with direct access to the artifact-dir. This would allow any build script to participate but Cargo couldn't report collisions and this would not be safe for concurrent access.

Build scripts could have a special directory to stage final artifacts. Cargo would then need to walk all of the staging directories, check for collisions, and then copy them over to the artifact-dir. This does make predicting and resolving collisions by users more difficult as a user needs to track what every build script in their dependency tree does. This may also have a performance impact if the build script can directly generate to the staging directory and needs to copy them over but they are unused by the user.

When discussing expanding the ability for build scripts to communicate with dependents (#3544), another idea came up. We can introduce a new build script directive for specifying an artifact, both where it comes from and where it should be placed, relative to the artifact-dir. These artifacts would only be uplifted into the artifact-dir for selected packages, the same rule that applies to existing artifacts. A build script could read cargo::metadata output from a dependency's build script and generate an artifact build script directive for it.

So going back to our criteria

Any build script will be able to generate a final artifact though it does require some manual work
Cargo could check the build script directives and report an error for collisions. Users will have full visibility into collisions and autonomy for responding to these errors as they own all of the affected build scripts. The errors would come at the end of the build which is unfortunate.
Cargo will be doing the uplifting and can ensure the locations it will access are locked

This can serve as a polyfill for RFC #3035 (postponed), providing a workaround for it and allowing for further experimentation. One way this is lacking as a polyfill is artifact dependencies support. We could name the directive artifact and automatically create artifact dependency variables when you depend on the package, rather than requiring #3544. The artifact could be named for the destination but if we allow directories as destinations, we don't have a unique name. Depending on artifacts from a package would also be implicit in the dependency specification unlike regular artifact dependencies.

Some open questions on this include

what to name it? copy, artifact, copy-artifact, or something else?
what should the copy semantics be when source or destination is a directory without a trailing /?
what separator should be used between the source and destination?
when copying directories, do we check whether directories collide or their content?
if and how we tie this to the artifacts dependency system

One potential route forward is to defer a connection to artifact dependencies and either make sure the design can handle adding it later or make the design low level and build an artifact solution on top of it later.

Target dir locking

One thing that slows down builds is being blocked on another build, particularly when running cargo check on the command-line while rust-analyzer is also running cargo check. This happens because the entire target directory underneath target/<platform>/<profile> is managed by a single lock to avoid concurrent builds from negatively impacting each other.

ranger-ross is working towards a cross-project cache (#5931) with build dir layout changes being one stepping stone. They decided to explore a finer-grained locking scheme for the target directory as a user-facing deliverable on top of the build dir layout changes as well as to explore caching schemes for the cross-project cache, assuming we can get reuse.

A target dir is usually made up of two concepts, a build dir for intermediate artifacts (e.g. rlibs) and an artifacts dir for final artifacts (e.g. binaries). We've organize the build dir around build units for Cargo to lock them individually. Before any build unit locking can be meaningful, we need to adjust how we lock the artifacts dir. As most of the concern is about cargo check vs cargo check / cargo clippy / cargo run / cargo test, ranger-ross took the simple approach and split the build dir and artifacts dir locks, avoiding grabbing the artifacts dir lock when no artifacts are produced. This won't help against cargo build, cargo run, cargo test, or cargo bench running in parallel which is likely fine as these are less likely to need to run in parallel.

As for locking intermediate build unit artifacts individually, things got complicated. The straight forward way to start is to grab any needed locks around the operation that needs protection. This means each build unit will grab an exclusive lock for itself and a shared lock for all dependencies. This runs into several complications:

prevents pipelined compilation as later build units need to wait for the rlib to be generated when they might have only needed the rmeta.
performance impact of each build unit grabbing a lock for every dependency
quickly hitting ulimit's, especially with each build unit grabbing a lock for every dependency

We had hoped to avoid some of this by using a single (read or append) xor exclusive-write lock for all of the build dir. The first problem is that build units are mutable and we don't know ahead of time if we'll be mutating them. You can see what build inputs can mutate cache entries by comparing Fingerprints to Metadata::c_metadata. If we made cache entries immutable, we'd see an explosion of cache entries as one will exist for every cargo check run done by rust-analyzer when editing your source. This would block the locking effort on build-dir GC (#5026) and likely need different reclamation times for different types of entries so Cargo preserves the most relevant ones. This would have the benefit of not rebuilding when switching back and forth between branches. However, an even bigger problem is present: we need a build to discover the source files to find out if a cache entry exists. For the cross-project cache, that won't be an issue because we expect Cargo will only be storing entries in that cache for immutable packages.

When exploring the per-build-unit lock design, ranger-ross optimized it by caching locks for dependencies. This led to the idea of having the top-level build operation own the locks that are lazily acquired, ensuring we'd need at most one lock per build unit.

This design is being further explored on Zulip and in #16155.

Structured logging

This is a project goal to add structured logging to Cargo so users can view timings and rebuild reasons for past builds, avoiding the frustration of "why was that slow" or "why did that rebuild" particularly when the build result is not reproducible.

weihanglo added structured logging support to cargo (#16150) fleshed it out ( #16179, #16203, #16282, #16303, #16346, #16350, #16378, ) and added cargo report timings (#16377).

You can enable this for nightly toolchains by adding to your ~/.cargo/config.toml

[build.analysis]
enabled = true

There is still a lot to figure out on the path to stabilization, including:

The data schema, especially if we want to work towards unifying this schema with Cargo's json output which would improve Cargo's json output (#8283) which would unblock a new, faster, more flexible architecture for cargo fix (e.g. cargo-fixit#68). See also Zulip
The interface for the new cargo report commands

Config include

-Zconfig-include allows for a .cargo/config.toml file to include others, e.g.

include = ["frodo.toml", "samwise.toml"]

This has been stuck in unstable limbo since 2019 with various concerns. There was an attempt to stabilize it in 2024 with the intent of expanding it in the future. There was a desire to ensure we could support those future possibilities before preceding.

weihanglo picked up the work on this, starting with merging of arrays of tables across layers (#16103), having only supported arrays of strings before. They then added support for include being specified by an array of tables (#16174). This will allow for adding fields in the future to customize the include behavior, like declaring an include optional (#16180).

As for allowing templates and globs in the future, the original thought was to opt-in via fields on the config table. However, other parts of Cargo directly support templates or globs. We deferred the decision on this by erroring if glob or template syntax is present (#16285) which will allow us to go down either route in the future.

Another question that came up during stabilization is what syntax forms are allowed and encouraged. At this point, the following were supported:

include = "a.toml"

include = [
  "a.toml",
  "b.toml",

]

include = [
  { path = "a.toml" },
  { path = "b.toml" },
]

[[include]]
path = "a.toml"
[[include]]
path = "b.toml"

In TOML, there is no logical difference between an array of inline-tables and an Array-of-Tables but which syntax is used can affect both the user and the design. If Array-of-Tables is our encouraged syntax, then we should likely drop include = "" and include = [""] as those are shorthands that require transforming the code to a different structure when new features are needed. An array of inline-tables has the problem that it is a top-level key which can be confusing in TOML because the root table is order dependent (has to be at the top) unlike any other table. In this case, that can be a strength because include is special and changes how the file is processed, so it likely should be at the top to help call attention to it. We decided to prefer an array of inline-tables in our documentation and in any future .cargo/config.toml style guide. weihanglo updated the docs in #16301. We decided to drop the include = "" form as too specialized. weihanglo did this in #16298.

One workflow annoyance with .cargo/config.toml is config files specific to both a project and a user (#14565). If a project commits their config file, the only option for the user is to move the repo into a subdirectory that they put their own config file in. If a project does not commit a config file, a user can create one but it won't be ignored by default in git and users frequently commit any file that shows up in git status. With -Zconfig-include, projects could gitignore a .cargo/config.user.toml and have:

include = [
    { path = "config.user.toml", optional = true }
]

However, this requires projects to update their MSRV and choose to adopt this convention. Improving this now is worth considering for any impact on the design of config-include that we can't change once stabilized. For example, .cargo/ has very little use today but that can change after -Zconfig-include is stabilized. What if we reserved a name like .cargo/config.user.toml before stabilizing so we could auto-load that file and have cargo init gitignore it? In addition to designing enough to know what to reserve, this overlooks the existence of --config PATH for which users could have their own files in .cargo/, increasing the chance someone would be negatively impacted by reserving the name. Blocking stabilizing -Zconfig-include on researching the answers to these questions did not seem worth it. There are still other options, for example .cargo/config/ is reserved by happenstance of Cargo always assuming .cargo/config is a TOML file and erroring if it is a directory.

weihanglo stabilized this feature in #16284.

`pubtime`

Recently, there has been an increased interest in supporting gradual rollouts of new package versions by giving users control over how old a package's version must be before being allowed to upgrade to it.

The first step for Cargo to support this is to know the publish time of registry packages. Cargo's dependency resolution operates off a Summary from the Registry Index. We need to extend that format with the publish time (#15491) and have crates.io do a backfill while gracefully handling registries that don't provide this information. After discussion with the crates.io team, epage implemented support for this within Cargo as well as "time traveling dependency resolution" (#5221) as an end-user way of exploring this functionality in #16265 Turbo87 implemented support in the staging instance of crates.io in crates.io#12315. In preparation for stabilization of this Summary field, the Cargo team discussed the design and epage applied the feedback in #16369. They then posted the stabilization request in #16372.

While "time traveling dependency resolution" via cargo generate-lockfile --publish-time 2025-12-01T01:01:01Z is straightforward to implement, it isn't as easy to stabilize. This only works for registry packages where the registry provides the needed information. Even then it is incomplete as we only track the latest yanked state, rather than the history of yanking and unyanking. We'd need to make sure we don't over-promise to the user what this can accomplish. We also need to clearly communicate what is happening to the user when the feature is active. These unresolved issues are being tracked in #16271.

On #15973, there is on-going exploration of requirements, prior art, and designs for minimumReleaseAge.

Misc

osiewicz added --workspace to cargo clean (#16263)
osiewicz sped up cargo clean -p and cargo clean --workspace (#16264)
weihanglo added net.git-fetch-with-cli support to git shallow clones (#16156)
Muscraft added spell checking to cargo's source and documentation(#16122)
(Update from 1.90) orhun is exploring an interactive pager-like TUI for cargo tree at cargo-tree-tui as a testing ground for extending other commands with them, see also Zulip.
(Update from 1.92) epage further polished Cargo Script (#16334, #16248, #16169)
weihanglo posted #16309 for an unstable feature for speeding up rustdoc builds.

Focus areas without progress

These are areas of interest for Cargo team members with no reportable progress for this development-cycle.

Project goals in need of owners

Stabilize public/private dependencies

Ready-to-develop:

Open namespaces
Auto-generate completions
- See clap-rs/clap#3166

Planning:

Disabling of default features
RFC #3416: features metadata
- RFC #3487: visibility (visibility)
- RFC #3486: deprecation
- Unstable features
Pre-RFC: Global, mutually exclusive features
RFC #3553: Cargo SBOM Fragment
OS-native config/cache directories (ie XDG support)

How you can help

If you have ideas for improving cargo, we recommend first checking our backlog and then exploring the idea on Internals.

If there is a particular issue that you are wanting resolved that wasn't discussed here, some steps you can take to help move it along include:

Summarizing the existing conversation (example: Better support for docker layer caching, Change in Cargo.lock policy, MSRV-aware resolver )
Document prior art from other ecosystems so we can build on the work others have done and make something familiar to users, where it makes sense
Document related problems and solutions within Cargo so we see if we are solving to the right layer of abstraction
Building on those posts, propose a solution that takes into account the above information and cargo's compatibility requirements (example)

Rustup 1.29.0 beta: Call for Testing!

2025-12-20T00:00:00+00:00

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

What's new

Following the footsteps of many package managers in the pursuit of better toolchain installation performance, the headline of this release is that rustup has been enabled to download components concurrently and unpack during downloads in operations such as rustup update or rustup toolchain and to concurrently check for updates in rustup check, thanks to a GSoC 2025 project. This is by no means a trivial change so a long tail of issues might occur, please report them if you have found any! pr#4388 pr#4426 pr#4436 pr#4455 pr#4471 pr#4605

As usual, we would be happy to receive regression/breakage reports of any kind, especially regarding the installation and/or usage on the following environments:

New host platforms:
- sparcv9-sun-solaris pr#4380
- x86_64-pc-solaris pr#4380
New shells:
- tcsh pr#4459
- xonsh pr#4626
Environments where you would like to bring your own rust-analyzer binary (such as r-a developers and certain Neovim/Helix users): rustup will now consider the rust-analyzer binary from PATH when the rustup-managed one is not found. pr#4324

Environments where you would like to override an environment variable back to the default: rustup now treats empty values as unset. pr#4422

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.

Finally, please don't forget to check out the corresponding section in our CHANGELOG.md for the complete list of changes included in this version.

Acknowledgements

A big thank you to:

@djc for continuously polishing the codebase to get rid of a whole lot of historical burden and carefully shaping the final form of preliminary concurrency support we have today;
@ChrisDenton for the careful handling of IO and Windows-related complexities;
@FranciscoTGouveia for joining me in the GSoC event to investigate the possibilities and lay the foundation of concurrency in rustup;
@Kobzol for enabling and organizing rustup's participation in GSoC 2025 and improving our CLI's cold start performance;
... and many other contributors who have made this new release possible!

Many thanks for everyone's continued support! Wishing you a magical holiday season surrounded by love, peace, and laughter 🍀

Inside Rust Blog

This Development-cycle in Cargo: 1.94

This Development-cycle in Cargo: 1.94

Plugin of the cycle

Implementation

Build dir layout

Target dir locking

Structured logging

TOML 1.1

cargo-cargofmt

lockfile-path

Design discussions

Workspace and configuration discovery

Misc

Focus areas without progress

How you can help

Leadership Council March 2026 Representative Selections

Criteria for representatives

What do Representatives do?

How should teams make their selection?

Program management update — January 2026

Project goals

2026 changes

Hiring a second Program Manager

Rust for Linux

CPython collaboration

cargo-script

Crates.io mirroring and verification

Worth a look

Rust Foundation posts

Rust blog posts

Stats

January 2026 Project Director Update

First look at 2026 Project goals

We want your feedback!

Questions

Frequently asked questions

Why are you saying 2026 goals and not 2026H1 goals?

What is the process timeline?

What if I have a goal I would like to propose? Is it too late?

I'd like to propose a goal, but I would need funding to work on it. Is there funding available for Project goals?

What is a "Flagship Theme"?

Can I propose a new flagship theme?

I see a "small|medium|large" ask of my team, what does that mean?

Can you give me some examples of what small|medium|large means?

What is a team champion?

Can I champion my own goal?

Why do you call these Project goals if some of them originate from outside the Project?

2025 Rust Foundation Annual Report Project Director Update

Infrastructure Team 2025 Q4 Recap and Q1 2026 Plan

Q4 2025 Accomplishments

More settings configured in the team repo

GitHub environments

Trusted publishing

Crates.io index and docs.rs served via Fastly

The new Bors is used to merge Rust compiler pull requests

rustc-perf benchmarks are now executed in parallel

Repository default branch renames

Hired a new teammate

Triagebot enhancements

Triagebot label command now supports aliases

Turn automatic backport nominations into suggestions

New Triagebot commands: r? me and @rustbot reroll

[no-mentions] handler removed from Triagebot

Highlighting of log lines in Triagebot’s GHA log viewer

Triagebot [mentions] now supports glob patterns

Internal Sites team takes its first action

Q1 2026 Plans

Finish Q4 2025 goals

Account and Access Management

Move to GitHub Rulesets

Join us!

What is maintenance, anyway?

Keeping the lights on

Enabling evolution

Conclusion

This Development-cycle in Cargo: 1.93

This Development-cycle in Cargo: 1.93

Plugin of the cycle

Implementation

`cargo-cargofmt`

More settings configured in the `team` repo

New Triagebot commands: `r? me` and `@rustbot reroll`

`[no-mentions]` handler removed from Triagebot

Triagebot `[mentions]` now supports glob patterns

`pubtime`