Rust Project Goals

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.

We've now opened our first batch of RFCs: rust-lang/rfcs#3873, rust-lang/rfcs#3874 and rust-lang/rfcs#3875

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

#t-compiler > 2025H2 Goal Review @ 💬

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

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.

Status update as of November 1

Key developments:

• Draft PR for exposing implied bounds in rustdoc JSON: https://github.com/rust-lang/rust/pull/148379
• A concrete plan for how that new info turns into dozens of new lints covering many kinds of bounds

Linting ?Sized and 'static bounds turned out to be quite a bit more complex than I anticipated. The key issue is that seeing T: Foo + ?Sized does not guarantee that T can be unsized, since we might have Foo: Sized which renders the ?Sized relaxation ineffective. Similarly, seeing T: Foo might also non-obviously imply T: 'static via a similar implied bound.

Failure to correctly account for implied bounds would lead to catastrophic false-positives and false-negatives. For example, changing T: Foo to T: Foo + 'static could be a major breaking change or a no-op, depending on whether we have Foo: 'static (either directly or implicitly via other trait bounds).

We cannot determine implied bounds using information present in rustdoc JSON today, so the rustdoc team and I have been iterating on the best way to compute and include that information in rustdoc JSON. Assuming something similar to the aforementioned PR becomes part of rustdoc JSON, cargo-semver-checks stands to gain several dozen new lints covering these tricky cases over trait associated types, generic type parameters, and APIT/RPIT/RPITIT.

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.

Instead of using a full-fledged database like SQLite, we switched to a basic JSONL-based logging system to collect build metrics. A simple design doc can be found here: https://hackmd.io/K5-sGEJeR5mLGsJLXqsHrw.

Here are the recent pull requests:

• https://github.com/rust-lang/cargo/pull/16150
• https://github.com/rust-lang/cargo/pull/16179

To enable it, set CARGO_BUILD_ANALYSIS_ENABLED=true or set the Cargo config file like this:

[build.analysis]
enabled = true

As of today (nightly-2025-11-03), it currently emits build-started and timing-info two log events to $CARGO_HOME/log/ (~/.cargo/log/ by default). The shape of timing-info JSON is basically the shape of the unstable --timing=json. I anticipate when this is stabilized we don't need --timing=json.

The build.analysis.enable is a non-blocking unstable feature. Unless bugs, should be able to set unconditionally even on stable toolchain. When not supported, it would just warn the unknown config merely.

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.