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

The Rust Foundation is opening up a short-term, approximately 3-month, contracting role to assist in our Rust/C++ Interop initiative. The primary work and deliverables for the role will be to make substantial progress on the Problem Space Mapping Rust Project Goal by collecting discrete problem statements and offering up recommendations on the work that should follow based upon the problems that you found.



If you are interested in how programming languages interoperate, are curious in understanding the problems therein, and are have a passion to think about how those problems may be resolved for the betterment of interop, then this work may be for you.

An ideal candidate will have experience with Rust programming. Having experience in C++ is strongly preferred as well. If you have direct experience with actual engineering that required interoperating between Rust and C++ codebases, that's even better.



If you are interested, please email me (email address found in my GitHub profile) or contact me directly on Zulip by Tuesday, January 27 and we can take it from there to see if there may be a potential fit for further discussion.

Thank you.

The effort to fill the contracting role to support this project goal is in the process winding down. The interview and discussion process is nearly complete. We expect to make a final decision for the role in early February.

Boxy and I have established a regular time to check-in on formalizing this within a-mir-formality. Today we mostly worked on the "model" of const values, starting with this

#![allow(unused)]
fn main() {
#[term]
pub enum ConstData {
    // Sort of equivalent to `ValTreeKind::Branch`
    #[cast]
    RigidValue(RigidConstData),

    // Sort of equivalent to `ValTreeKind::Leaf`
    #[cast]
    Scalar(ScalarValue),

    #[variable(ParameterKind::Const)]
    Variable(Variable),
}



#[term]
pub enum ScalarValue {
    #[grammar(u8($v0))]
    U8(u8),
    #[grammar(u16($v0))]
    U16(u16),
    #[grammar(u32($v0))]
    U32(u32),
    #[grammar(u64($v0))]
    U64(u64),
    #[grammar(i8($v0))]
    I8(i8),
    #[grammar(i16($v0))]
    I16(i16),
    #[grammar(i32($v0))]
    I32(i32),
    #[grammar(i64($v0))]
    I64(i64),
    #[grammar($v0)]
    Bool(bool),
    #[grammar(usize($v0))]
    Usize(usize),
    #[grammar(isize($v0))]
    Isize(isize),
}


#[term($name $<parameters> { $,values })]
pub struct RigidConstData {
    pub name: RigidName,
    pub parameters: Parameters,
    pub values: Vec<Const>,
}
}

i.e., a const value can be a scalar value (as today) or a struct literal like Foo { ... } (which would also cover tuples and things). We got the various tests passing. Huzzah!

In addition to what niko posted previously there's been a lot of other stuff happening. A lot of people have opened PRs to improve mGCA this month: León Orell Valerian Liehr Noah Lev @enthropy7 Kivooeo @mu001999 @Human9000-bit Redddy @Keith-Cancel @AprilNEA

A rough list of things that have been improved for mGCA:

• Lots of new expressions now supported by mGCA: const constructors, tuple constructor calls, array expressions, tuple expression, literals
• associated_const_equality has been merged into min_generic_const_args. the former was effectively dependent on the latter already so this just makes it nicer to use the former :)
• traits can now be dyn compatible if all associated constants are type consts and are specified in the trait object (e.g. dyn Trait<ASSOC = 10>)
• type consts are enforced to be non-generic
• a bunch of ICEs have been fixed
• camelid has been working on "non-min" version of mGCA which will allow arbitrary expressions to be used in the type system (a blog post with more detail will be published once this actually lands)

In non-mGCA updates, as niko says, we've been meeting regularly to make progress on modelling const generics in a-mir-formality. I've also been spending time thinking about the interactions between adt_const_params and ADTs with privacy/safety invariants and I think I know how to structure the RFC in this area so can make progress on that again

There's some more detail about the various bits of work people have done and who did what here: #project-const-generics > perfectly adequately sized wins @ 💬

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

Earlier this month, [@Nadrieril][] Ding Xiang Fei and I held a meeting on autoref and method resolution in a world with field projections. This meeting resulted in a new page for the wiki on autoref.

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.

Key developments:

std::autodiff is moving closer to nightly, and std::offload is gaining various performance, feature, and hardware support improvements.

autodiff

Jakub Beránek, @sgasho, and I continued working on enabling autodiff in nightly. We have a PR up that builds autodiff in CI, and verified that the artifacts can be installed and work on Linux. For apple however, we noticed that any autodiff usage hangs. After some investigation, it turns out that we ended up embedding two LLVM copies, one in rustc, and one in Enzyme. It should be comparably easy to get rid of the second one. Once we verified that this fixes the build, we'll merge the PR to enable autodiff on both targets in nightly.

offload

A lot of interesting updates on the performance, feature, and hardware support side.

1. Marcelo Domínguez, @kevinsala, @jdoerfert, and I started implementing the first benchmarks, since that's generally the best way to find missing features or performance issues. We were positively surprised by how good the out-of-the-box performance was. We will implement a few more benchmarks and post the results once we have verified them. We also implemented multiple PRs which implement bugfixes, cleanups, and needed features like support for scalars. We also started working on LLVM optimizations which make sure that we can achieve even better performance.

2. I noticed that our offload intrinsic allowed running Rust code on the GPU, but it wasn't of much help when calling gpu vendor libraries like cuBLAS. In https://github.com/rust-lang/rust/pull/150683 I implemented a new helper intrinsic which allows calling those functions conveniently, without having to manually move data to or from the device. It will benefit from the same LLVM optimizations as our full offload intrinsic. It also a bit simpler to set up on the compiler and linker side, so it already works with std and mangled kernel names, something that we still have to improve for our main offload intrinsic.

3. A lot of work happened on the LLVM offload side for SPIRV and Intel GPU support. At the moment, our Rust frontend is tested on NVIDIA and AMD server and consumer GPUs, as well as AMD HPC and Lapotop APUs. Karol Zwolak reached out since he wants to help with with also running Rust on Intel GPUs. Offload relies on LLVM which started gaining Intel support, so hopefully we won't need much work beyond a new intel-gpu target and a new stdarch module. There is also work on a new spirv target for rustc, which we could also support if it goes through LLVM. Due to some open questions around typed pointers it does not seem clear yet whether it will, so we will have to wait.

4. Nikita started working on updating our submodule to LLVM 22. This hopefully does not only brings some compile and runtime performance improvements, but also greatly simplifies how we can build and use offload. Once it landed I'll refactor our bootstraping logic, and as part of that start building offload in CI.

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.

Update from the 2026-01-14 meeting.

Deref / Receiver

Ding's arbitrary_self_types: Split the Autoderef chain rust#146095 is waiting on reviews. It updates the method resolution to essentially: deref_chain(T).flat_map(|U| receiver_chain(U)).

The perf run was a wash and a carter has completed yesterday. Analysis pending.

RFC #3851: Supertrait Auto-impl

Ding has submitted a Rust Project goal for Supertrait Auto Impl.

Arbitrary Self Types rust#44874

We've discovered the #[feature(arbitrary_self_types_pointer)] feature gate. As the Lang consensus is to not support the Receiver trait on raw pointer types we're probably going to remove it (but this needs further discussion). This was a remnant from the original proposal, but the Lang has changed direction since.

derive(CoercePointee) rust#123430

Ding is working on a fix to prevent accidental specialization of the trait implementation. rust#149968 is adding an interim fix.

Alice opened a Reference PR for rust#136776. There are questions around the behaviour of the as cast vs. coercions.

Pass pointers to const in assembly rfc#3848

Gary opened implementation for the RFC: rust#138618.

In-place initialization goal#395

Ding is writing a post to describe all the open proposals including Alice's new one that she brouhght up during the LPC 2025. He'll merge it in: https://rust-lang.github.io/beyond-refs.

Field Projections goal#390

Benno updated the Field Representing Types PR to the latest design. This makes the PR much simpler.

Tyler opened a wiki to keep all the proposals, resources in one place: https://rust-lang.github.io/beyond-refs.

Macros, attributes, derives, etc.

Josh brought up his work on adding more capable declarative macros for writing attributes and derives. He's asked the Rust for Linux team for what they need to stop using proc macros.

Miguel noted they've just added dependency on syn, but they would like to remove it some day if their could.

Benno provided a few cases of large macros that he thought were unlikely to be replacable by declarative-style ones. Josh suggested there may be a way and suggested an asynchronous discussion.

A proposal to continue this goal in the next goal period was merged: https://github.com/rust-lang/rust-project-goals/pull/477

There hasn't been too much progress over the last few weeks and I've been mostly taking a Christmas break. Nicholas Nethercote has been looking into the performance of the new trait solver, cleaning up canonicalization and slightly improving its performance: https://github.com/rust-lang/rust/pull/150748 https://github.com/rust-lang/rust/pull/150859.

Shoyu Vanilla looked into https://github.com/rust-lang/trait-system-refactor-initiative/issues/251 and uncovered the underlying bug there. While this issue also affects the old solver and the proper fix for it requires where-bounds on binders, we can work around this bug in the trait solver for now and intend to do so.

We've started another crater run with all our recent changes and adwin has started to triage it, uncovering one new issue up until now. Intend to continue going through that over the next few weeks.

There's also a lot in-progress work going on. I am collaborating with Niko Matsakis to specify and later RFC the cycle semantics of Rust. León Orell Valerian Liehr is working on a replacement for the rustdoc's auto trait impl synthesis: https://github.com/rust-lang/rust/pull/149019. @tiff is working on a fix a MIR borrowck unsoundness: https://github.com/rust-lang/trait-system-refactor-initiative/issues/159. Shoyu Vanilla and I are improving the way we propagate inference constraints from the expected return type to function arguments, fixing https://github.com/rust-lang/trait-system-refactor-initiative/issues/259.

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.

This month's update:

• tiif is making progress on https://github.com/rust-lang/trait-system-refactor-initiative/issues/159
• we discussed how to investigate and fix the remaining correctness issues in Tage's work, to be able to evaluate it more accurately: in particular around variance and bidirectional edges, and without the reliance on NLL (having computed region values / errors)
• we've tried to see if it'd be possible to remove the cfg region elements
• Amanda is still working on her two papers, one about the current borrow checker and one about the work on Polonius. Her major PR for the restructuring of placeholder handling during region inference is stalled due to a conflict with further trait solver developments and may have to be abandoned. Work with the larger types team is ongoing and smaller patches/refactorings/improvements are being landed in the meantime.
• https://github.com/rust-lang/rust/pull/149639 has now landed, and https://github.com/rust-lang/rust/pull/150551 is still in review
• I've also fixed more small inefficiencies (computing boring/relevant locals on-demand in diagnostics, removed conversions between locations and points, etc) building on top of the previous PRs (so they need to be reviewed first)
• I've looked at crates.io again with the alpha, to find functions that are slower than with NLLs. AFAICT the worst case there is 60% for a 5KLOC function with 42K loans, 255K statements, and 125K outlives constraints. I'll see what we can do with this. Small composable functions is still good advice.
• there seem to be optimization opportunities to 1. limit propagation to the smaller number of blocks that could be affected by bidirectional edges, 2. for unifying invariant lifetimes of live locals that are assigned at most once (à la use-def chains), 3. for invalidations that are just the activation of a reservation
• we discussed possible plans to gather actual statistics, using the infrastructure that was created for the Metrics project
• we're also preparing the new project goal for this year, where we'll want to stabilize the alpha 🤞

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

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

Nothing this month, been busy with other stuff :)