Rust Project Goals

rust-lang/rfcs#3873 has been merged and an FCP has been started on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 - those both have some feedback for me to respond to that I'll get to as soon as I can

rust-lang/rfcs#3873 is waiting on one checkbox before entering the final comment period. We had our sync meeting on the 11th and decided that we would enter FCP on rust-lang/rfcs#3874 and rust-lang/rfcs#3875 after rust-lang/rfcs#3873 is accepted. We've responded to almost all of the feedback on the next two RFCs and expect the FCP to act as a forcing-function so that the relevant teams take a look, they can always register concerns if there are things we need to address, and if we need to make any major changes then we'll restart the FCP.

Our first RFC - rust-lang/rfcs#3873 - is in the FCP process, waiting on boxes being checked. rust-lang/rfcs#3874 and rust-lang/rfcs#3875 are receiving feedback which is being addressed.

I posted a "year in review" for cargo-semver-checks here: https://predr.ag/blog/cargo-semver-checks-2025-year-in-review/

It has a section on how I think we should move forward in 2026 and beyond: https://predr.ag/blog/cargo-semver-checks-2025-year-in-review/#the-path-forward-for-2026-and-beyond

Google Summer of Code 2025 is complete + finally some movement on cross-crate linting! 🚀

Key developments

• Two students had a successful conclusion of Google Summer of Code working on cargo-semver-checks — find more details here!
• rustdoc JSON now includes rlib information, following the design for cross-crate rustdoc JSON info created at RustWeek 2025: https://github.com/rust-lang/rust/pull/149043
• A cargo issue was discovered that prevents this rlib info from being used; it's currently being triaged: https://github.com/rust-lang/cargo/issues/16291
• Once that's resolved, we'll have enough here for a basic prototype. Getting features right in dependencies will likely require more work due to having many more cargo-related edge cases.

Key developments:

• libtest2:
  • #[test] macro added
  • Support for should_panic
  • Support for ignore
  • Support for custom error types
  • compile-fail tests for macros

Blockers

• None

Help wanted:

• Round out libtest compatibility

Hi @sladyn98 - feel free to ping me on Zulip about this.

The work is more on the compiler side atm, so Eric Holk and b-naber could speak more to where they could use help.

Ed Page hey i would like to contribute to this I reached out on zulip. Bumping up the post in case it might have gone under the radar

CC Niko Matsakis

Project Goal Update

The prototype of this project goal is basically complete.

Current state

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

At a high level, the prototype:

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

See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#build-analysis for a more thorough usage documentation

Path towards stabilization

Before this feature can be stabilized, the following unresolved questions must be answered.

They might not block stabilization, but need to be evaluated if it is fine to leave for future.

cargo report commands

This is a stabilization blocker.

• [ ] Currently all three report commands (sessions, rebuilds, timings) implicitly inspect global log files when if not in a workspace.
  • Should this be explicit with a flag?
  • Should this be an error if not in a workspace?
• [ ] Bikeshed on command names
  • Currently we have all nouns
    • For sessions
      • runs simple but ambiguous
      • Just log like git log
      • history user-friendly (docker history, shell history, though not alike)
    • For timings:
      • Not controversial, as we have --timings flag already
    • For rebuilds:
      • rebuild-reasons more explicit
  • Or move to action-oriented verbs:
  • cargo report list-sessions
  • cargo report analyze-timings (bazel analyze-profile https://bazel.build/docs/user-manual#analyze-profile)
  • cargo report explain-rebuilds
  • Or question-oriented verbs:
  • cargo report what-ran more general https://buck2.build/docs/developers/what-ran/
  • cargo report why-rebuilt/why-reran

cargo report sessions

• Currently it prints a human-readable output without a format for programmable use cases.
  • Should we provide a programmable output (for example behind --message-format=json)?

cargo report rebuilds

• Extend the report from fingerprint to new hash (-Cmetadata/-Cextra-filename)
  • We currently can't distinguish whether a fresh build is a real new build or just rustflags changed
  • https://github.com/rust-lang/cargo/pull/16456#discussion_r2662364819
• Make each rebuilt reason more actionable and friendly for end-users.
• Should we log the fingerprint values being compared, or just the diff result?
• #t-cargo > logging unit fingerprint @ 💬

Log message schema

This is a stabilization blocker.

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

Log infrastructure

These are mostly future possibilities, not a stabilization blocker, as it is highly possible to do incremental improvements.

• [ ] log compression https://github.com/rust-lang/cargo/issues/16475
• [ ] log rotation https://github.com/rust-lang/cargo/issues/16471
• [ ] Is losing data on crashes ok? https://github.com/rust-lang/cargo/pull//16150#discussion_r2462056940

See also https://github.com/rust-lang/cargo/issues/16471#issuecomment-3724915770

Nested Cargo calls

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

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

This is a stabilization blocker.

How contributors can help

Future contributors can help by:

• picking up any linked issues below or in https://github.com/rust-lang/cargo/issues/15844
• building external tools utilizing the log messages, and providing feedback
• providing real-world feedback from large or unusual builds

A series of follow-up tasks has been cut to track remaining work:

• https://github.com/rust-lang/cargo/issues/16470
• https://github.com/rust-lang/cargo/issues/16471
• https://github.com/rust-lang/cargo/issues/16472
• https://github.com/rust-lang/cargo/issues/16473
• https://github.com/rust-lang/cargo/issues/16474
• https://github.com/rust-lang/cargo/issues/16475
• https://github.com/rust-lang/cargo/issues/16477
• https://github.com/rust-lang/cargo/issues/16488

Key developments:

Headline: You should always enable build analysis locally, if you are using nightly and want the timing info data always available.

[unstable]
build-analysis = true

[build.analysis]
enabled = true

• More log events are emitted: https://github.com/rust-lang/cargo/pull/16390
  • dependency resolution time
  • unit-graph construction
  • unit-registration (which contain unit metadata)
• Timing replay from cargo report timings now has almost the same feature parity as cargo build --timings, except CPU usage: https://github.com/rust-lang/cargo/pull/16414
• Rename rebuild event to unit-fingerprint, and is emitted also for fresh unit: https://github.com/rust-lang/cargo/pull/16408.
• Proposed a new cargo report sessions command so that people can retrieve previous sessions IDs not use the latest one: https://github.com/rust-lang/cargo/pull/16428
• Proposed to remove --timings=json which timing info in log files should be a great replacement: https://github.com/rust-lang/cargo/pull/16420
• Documenting efforts for having man pages for nested commands `cargo report : https://github.com/rust-lang/cargo/pull/16430 and https://github.com/rust-lang/cargo/pull/16432

Besides implementations, we also discussed about:

• The interaction of --message-format and structured logging system, as well as log event schemas and formats: https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20analysis.20log.20format/with/558294271
• A better name for RunId. We may lean towards SessionId which is a common name for logging/tracing ecosystem.
• Nested Cargo calls to have a sticky session ID. At least a way to show they were invoked from the same top-level Cargo call.

Blockers: No, except my own availability

Help wanted: Same as https://github.com/rust-lang/rust-project-goals/issues/398#issuecomment-3571897575

Key developments: HTML replay logic has merge. Once it gets into nightly cargo report timings can open the timing report you have previously logged.

• https://github.com/rust-lang/cargo/pull/16377
• https://github.com/rust-lang/cargo/pull/16378
• https://github.com/rust-lang/cargo/pull/16382

Blockers: No, except my own availability

Help wanted: Same as https://github.com/rust-lang/rust-project-goals/issues/398#issuecomment-3571897575

Key developments: Started emitting basic fingerprint information, and kicked off the refactor of rendering HTML timing report for future report replay through cargo report timings command.

• https://github.com/rust-lang/cargo/pull/16203
• https://github.com/rust-lang/cargo/pull/16282

Blockers: no except my own availability

Help wanted: Mendy on Zulip brought up log compression (#t-cargo > build analysis log format @ 💬) but I personally don't have time looking at it durnig this period. Would love to see people create an issue in rust-lang/cargo and help explore the idea.

linking this here so people know why there hasn't been any progress on this project goal.

#t-compiler > 2025H2 Goal Review @ 💬

Status update January 15, 2026

Fine grain locking for build-dir was merged in https://github.com/rust-lang/cargo/pull/16155 and now available on nightly via -Zfine-grain-locking unstable flag. 🎉

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

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

Status update December 23, 2025

The majority of December was spent iterating on https://github.com/rust-lang/cargo/pull/16155 . As mentioned in the previous update, the original locking design was not correct and we have been working through other solutions.

As locking is tricky to get right and there are many scenarios Cargo needs to support, we are trying to descope the initial implementation to an MVP, even if that means we lose some of the concurrency. Once we have an MVP on nightly, we can start gathering feedback on the scenarios that need improvement and iterate.

I'm hopeful that we get an unstable -Zfine-grain-locking on nightly in January for folks to try out in their workflows.

Also we are considering adding an opt-in for the new build-dir layout using an env var (CARGO_BUILD_DIR_LAYOUT_V2=true) to allow tool authors to begin migrating to the new layout. https://github.com/rust-lang/cargo/pull/16336

Before stabilizing this, we are doing crater run to test the impact of the changes and proactively reaching out to projects to minimize breakage as much as possible. https://github.com/rust-lang/rust/pull/149852

Status update November 21, 2025

October was largely spent working out design details of the build cache and locking design.

https://github.com/rust-lang/cargo/pull/16155 was opened with an initial implementation for fine grain locking for Cargo's build-dir however it needs to be reworked after the design clarifications mentioned above.

In November I had a change of employer so I my focus was largely on that. However, we did make some progress towards locking in https://github.com/rust-lang/cargo/pull/16230 which no longer lock the artifact-dir for cargo check. This is expected to land in 1.93.0.

I'm hoping to push fine grain locking forward later this month and in December.

Key developments

• FCP has ended on frontmatter support, just awaiting merge (https://github.com/rust-lang/rust/pull/148051)
• Cargo script has entered FCP (https://github.com/rust-lang/cargo/pull/16569)

Blockers

• Potential issues around edition, see https://github.com/rust-lang/rust/issues/152254

Key developments

• #146377 has been decided and merged

Blockers

• T-lang discussing CR / text direction feedback: https://github.com/rust-lang/rust/pull/148051#issuecomment-3638326490
• T-rustdoc deciding on and implementing how they want frontmatter handled in doctests

Key developments

• A fence length limit was added in response to T-lang feedback (https://github.com/rust-lang/rust/pull/149358)
• Whether to disallow or lint for CR inside of a frontmatter is under discussion (https://github.com/rust-lang/rust/pull/149823)

Blockers

• https://github.com/rust-lang/rust/pull/146377
• rustdoc deciding on and implementing how they want frontmatter handled in doctests

Key developments

• rust-lang/rust#148051

Blockers:

• rustdoc deciding on and implementing how they want frontmatter handled in doctests