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

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

Here's our January status update!

• Yesterday, we posted an MCP for our retag intrinsics. While that's in progress, we'll start adapting our current prototype to remove our dependence on MIR-level retags. Once that's finished, we'll be ready to submit a PR.

• We published our first monthly blog post about BorrowSanitizer.

• Our overall goal for 2026 is to transition from a research prototype to a functional tool. Three key features have yet to be implemented: garbage collection, error reporting, and support for atomic memory accesses. Once these are complete, we'll be able to start testing real-world libraries and auditing our results against Miri.

Update from the 2026-01-14 meeting:

#![register_tool] rust#66079

Tyler Mandry proposed FCP of the RFC#3808 and nominated it for a Lang discussion.

-Zdebuginfo-compression rust#120953

Wesley Wiser proposed stabilization: rust#150625.

Josh Triplett suggested trying to bring zlib-rs in the kernel as a case study.

-Zdirect-access-external-data rust#127488

rust#150494 was merged two days ago, what reminds is updating the documentation and stabilizing the feature.

There's an ongoing discussion about the feature on the Rust Zulip as well.

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

• https://github.com/rust-lang/rust/pull/146923 has landed, and we even got the first contribs adding array support to reflection.
  • there are lots more types and type information that we could support, and it's rather easy to add more. Happy to review any work here.
• https://github.com/rust-lang/rust/pull/150033 has landed, and I'm working on removing the 'static requirement in https://github.com/rust-lang/rust/pull/150161

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.

The MCP (https://github.com/rust-lang/compiler-team/issues/951) has been seconded and is still waiting 3 days to be approved. Once that is done, we can proceed with merging the Tier 2 target.

rust-lang/rust#143924 has been merged, enabling scalable vector types to be defined on nightly, and I'm working on a patch to introduce unstable intrinsics/scalable vector types to std::arch