Rust Project Goals

Current status: there is an RFC for auto impl supertraits that has received some discussion and updates (thank you, Ding Xiang Fei!).

The major open questions currently are:

Syntax

The current RFC proposes:

#![allow(unused)]
fn main() {
trait Subtrait: Supertrait {
    auto impl Supertrait {
        // Supertrait items defined in terms of Subtrait items, if any
    }
}
}

Additionally, there is an open question around the syntax of auto impl for unsafe supertraits. The current proposal is to require unsafe auto impl Supertrait.

Whether to require impls to opt-out of auto impls

The current RFC proposes that

#![allow(unused)]
fn main() {
impl Supertrait for MyType {}
impl Subtrait for MyType {
// Required in order to manually write Supertrait
}
 for MyType.
extern impl Supertrait;
}

This makes it explicit via opt-out whether an auto impl is being applied. However, this is in conflict with the goal of allowing auto impls to be added to existing trait hierarchies. The RFC proposes to resolve this via a temporary attribute which triggers a warning. See my comment here.

Note that properly resolving whether or not to apply an auto impl requires coherence-like analysis.

The new solver is now officially used by Rust Analyzer: https://rust-analyzer.github.io/thisweek/2025/10/27/changelog-299.html. A huge shoutout to Jack Huey Chayim Refael Friedman Shoyu Vanilla and Laurențiu Nicola for that work.

On the rustc end Rémy Rakic spent a lot of time triaging the most recent crater run. This uncovered a bunch of new edge cases, resulting in 6 new tracked issues.

We've also merged fixes for 4 minor issues over the last 3 weeks: https://github.com/rust-lang/rust/pull/148292 https://github.com/rust-lang/rust/pull/148173 https://github.com/rust-lang/rust/pull/147840. Thanks to Jana Dönszelmann, tiif and [@adwinwhite][] for implementing these. [@adwinwhite][] was also instrumental in diagnosing the underlying issue of https://github.com/rust-lang/trait-system-refactor-initiative/issues/245.

Going forward, we intend to continue the crater triage while fixing remaining issues until we're ready for stabilization :> the remaining issues are tracked in https://github.com/orgs/rust-lang/projects/61/views/1.

Since the last update we've fixed the hang in rayon in https://github.com/rust-lang/rust/pull/144991 and https://github.com/rust-lang/rust/pull/144732 which relied on https://github.com/rust-lang/rust/pull/143054 https://github.com/rust-lang/rust/pull/144955 https://github.com/rust-lang/rust/pull/144405 https://github.com/rust-lang/rust/pull/145706. This introduced some search graph bugs which we fixed in https://github.com/rust-lang/rust/pull/147061 https://github.com/rust-lang/rust/pull/147266.

We're mostly done with the opaque type support now. Doing so required a lot of quite involved changes:

• https://github.com/rust-lang/rust/pull/145244 non-defining uses in borrowck
• https://github.com/rust-lang/rust/pull/145925 non-defining uses in borrowck closure support
• https://github.com/rust-lang/rust/pull/145711 non-defining uses in hir typeck
• https://github.com/rust-lang/rust/pull/140375 eagerly compute sub_unification_table again
• https://github.com/rust-lang/rust/pull/146329 item bounds
• https://github.com/rust-lang/rust/pull/145993 function calls
• https://github.com/rust-lang/rust/pull/146885 method selection
• https://github.com/rust-lang/rust/pull/147249 fallback

We also fixed some additional self-contained issues and perf improvements: https://github.com/rust-lang/rust/pull/146725 https://github.com/rust-lang/rust/pull/147138 https://github.com/rust-lang/rust/pull/147152 https://github.com/rust-lang/rust/pull/145713 https://github.com/rust-lang/rust/pull/145951

We have also migrated rust-analyzer to entirely use the new solver instead of chalk. This required a large effort mainly by Jack Huey Chayim Refael Friedman and Shoyu Vanilla. That's some really impressive work on their end 🎉 See this list of merged PRs for an overview of what this required on the r-a side. Chayim Refael Friedman also landed some changes to the trait solver itself to simplify the integration: https://github.com/rust-lang/rust/pull/145377 https://github.com/rust-lang/rust/pull/146111 https://github.com/rust-lang/rust/pull/147723 https://github.com/rust-lang/rust/pull/146182.

We're still tracking the remaining issues in https://github.com/orgs/rust-lang/projects/61/views/1. Most of these issues are comparatively simple and I expect us to fix most of them over the next few months, getting us close to stabilization. We're currently doing another crater triage which may surface a few more issues.

Here's another summary of the most interesting developments since the last update:

• reviews and updates have been done on the polonius alpha, and it has since landed
• the last 2 trivial diagnostics failures were fixed
• we've done perf runs, crater runs, completed gathering stats on crates.io for avg and outliers in CFG sizes, locals, loan and region counts, dataflow framework behavior on unexpected graph shapes and bitset invalidations
• I worked on dataflow for borrowck: single pass analyses on acyclic CFGs, dataflow analyses on SCCs for cyclic CFGs
• some more pieces of amanda's SCC rework have landed, with lcnr's help
• lcnr's opaque type rework, borrowcking of nested items, and so on, also fixed some issues we mentioned in previous updates with member constraints for computing when loans are going out of scope
• we also studied recent papers in flow-sensitive pointer analysis
• I also started the loans-in-scope algorithm rework, and also have reachability acceleration with the CFG SCCs
• the last 2 actual failures in the UI tests are soundness issues, related to liveness of captured regions for opaque types: some regions that should be live are not, which were done to help with precise capture and limit the impact of capturing unused regions that cannot be actually used in the hidden type. The unsoundness should not be observable with NLLs, but polonius alpha relies on liveness to propagate loans throughout the CFG: these dead regions prevent detecting some error-causing loan invalidations. The easiest fix would cause breakage in code that's now accepted. niko, jack and I have another possible solution and I'm trying to implement it now

Continued work this week:

Elaborated some on the definition of the when an access or a statement is valid. We are working our way towards what we believe will be a "largely accurate" model of today's NLL -- obviously we'll then want to test it and compare behavior around various edge cases.

tiif, Jack Huey, and I met today and did more work on the "living-large" branch. The borrow checker judgments are taking shape. My expectation is that we will walk the CFG, tracking the sets of borrows that have occurred so far. At each statement, we will have a judgment that looks at (a) the subtyping relations generated by the type check (flow-insensitive, like NLL); (b) the loans issued so far and not killed; and (c) the live places that may be accessed later. We'll require then that if you are accessing a place P, then there are no loans accessible from a live place that have borrowed P in an incompatible way.

tiif and I have been meeting weekly here and pushing changes to the living-large branch of a-mir-formality/nikomatsakis.

We are making progress, we have a minirust type checker and the start of a borrow checker. We've decided to try to use a "judgment-like" approach rather than modeling this as dataflow, as I believe it will give greater insight into the "structure" of the trait checker.

A bit late on this update but I've sat down with lcnr a little while back and we tried to come up with a list of topics that we felt fell under type system documentation. This is an entirely unordered list and some topics may already be adequately covered in the dev guide already.

Regardless this effectively serves as a "shiny future" for everything I'd like to have documentation about somewhere (be it dev guide or in-tree module level documentation):

• opaque types
  • non defining vs defining uses
  • member constraints (borrowck overlap)
  • checking item bounds
  • high level normalization/opaque type storage approach (new solver)
  • normalization incompleteness
  • method/function incompleteness
  • how does use<...> work
  • 'erased regions causes problems with outlives item bounds in liveness
  • consistency across defining scopes
  • RPITIT inference? does this have special stuff
  • capturing of bound vars in opaques under binders, Fn bounds are somewhat special in relation to this
  • opaques inheriting late bound function parameters
• non opaque type, impl Trait
  • RPITIT in traits desugaring
  • impl Trait in bindings
  • APIT desugaring impl details
• const generics
  • anonymous constants
  • ConstArgHasType
  • TSVs vs RVs and generally upstream doc from lang meeting to dev guide
  • deterministic CTFE requirement
• HIR typeck
  • expectations (and how used incorrectly :3)
  • method lookup + assorted code cleanups
  • coercions
  • auto-deref/reborrows (in coercions/method selection)
  • closure signature inference
  • fudge_inference_if_ok :>
  • diverging block handling :3
  • fallback :3
• MIR borrowck
  • MIR typeck
    • why do we want two typecks
    • region dependent goals in new solver (interaction with lack-of region uniquification)
  • overlaps with opaque types
  • compute region graph
  • closure requirements
  • borrowck proper
• compare predicate entailment :>
  • param env jank
  • implied bounds handling
• trait objects: recent FCPs :3
  • dyn compatibility soundness interactions (see coerce pointee/arbitrary self types stuff)
  • dyn compatibility for impl reasons (monomorphization)
  • projection bounds handling
  • args not required for wf
• ty::Infer in ty overview
• generalization
• coroutines
  • deferred coroutine obligations
  • witness types?
  • why -Zhigher-ranked-assumptions exists
• binders and universes existsA forallB A == B
  • build more of an intuition than current docs :thinking_face:
• talk about hr implied bounds there/be more explicit/clear in https://rustc-dev-guide.rust-lang.org/traits/implied-bounds.html?highlight=implied#proving-implicit-implied-bounds
• incompleteness
  • what is it
  • what kinds are OK (not entirely sure yet. small explanation and add a note)
• trait solving
  • cycles
  • general overview of how trait solving works as a concept (probably with example and handwritten proof trees)
    • important: first go "prove stuff by recursively proving nested requirements", then later introduce candidates
    • clauses/predicates
  • running pending goals in a loop
  • what kinds of incompleteness (overlap with opaques)
  • builtin impls and how to add them
• hir to ty lowering :>
  • itemctxt vs fnctxt behaviours
  • normalization in lowering
  • lowering should be lossy
  • idempotency(?)
  • cycles from param env construction
  • const generics jank about Self and no generic parameters allowed
• well formedness checking + wf disambiguation page
• normalization & aliases
  • be more clear about normalizing ambig aliases to infer vars :thinking_face:
  • normalize when equating infer vars with aliases (overlap with generalization?)
  • item bounds checking
  • interactions with implied bounds (overlap with implied bounds and hir ty lowering)
• variance

Since making this list I've started working on writing documentation about coercions/adjustments. So far this has mostly resulted in spending a lot of time reading the relevant code in rustc. I've discovered a few bugs and inconsistencies in behaviour and made some nice code cleanups which should be valuable for people learning how coercions are implemented already. This can be seen in #147565

I intend to start actually writing stuff in the dev guide for coercions/adjustments now as that PR is almost done.

I also intend to use a zulip thread (#t-compiler/rustc-dev-guide > Type System Docs Rewrite) for more "lightweight" and informal updates on this project goal, as well as just miscellaneous discussion about work relating to this project goal