rustc trait system rewrite initiative

[lcnr]

Proposal

Start an initiative with the goal of replacing the current trait system implementation of rustc. This new implementation should fully replace both fulfill and evaluate and offer an API a lot closer to the ideal of chalk/a-mir-formality.

Goals of this initiative

• greatly simplify future changes to the trait system, unblocking features like marker traits and fixes for existing soundness bugs
• better learnability, the current system is difficult to learn and understand
• far better[^1] caching with an estimated impact of
  • reducing compilation-time of some real world crates to less than half
  • for less type-heavy crates 0% and 15% improvements
  • in rare cases, may initially slightly worsen performance
• reduces the chance of trait system bugs in the future

[^1]: currently different FnCtxt and ObligationCtxt do not share a cache for fulfill and also don't share it with mir borrowck.

Explicit non-goals of this initiative

This initiative does not intend to implement any major changes to the trait system as part of the replacement. The new replacement should closely mirror the old system at the time of replacement to minimize the risk of backwards compatibility issues.

We also do not intend to extract any shared code with rust-analyzer as part of this initiative. While that will be easier after this work has been completed, the sole focus of this initiative is to replace the existing solvers with a solver which results in the advantages noted above.

Outline of the planned work

Start by clearly laying out how the compiler uses the existing trait solvers and what API has to be provided by the new solver.

Any parts strongly tied to the architecture of the current solvers have to be rewritten where possible. The biggest challenge will be trait diagnostics, which should be rewritten to be as solver agnostic as possible. Instead of relying on solver internals, diagnostics should lazily recompute necessary information where possible. This may require a reimplementation of our trait diagnostics to replace the existing one.

Once this is done, work on a new solver directly in rustc to replace both evaluate and fulfill. When that solver is ready, replace all uses of evaluate and fulfill with the new solver and remove evaluate and fulfill. At that point this initiative can be closed again.

For more information, see this document

Initial members

@lcnr as lead, other Types Team members depending on interest.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/types

[lcnr]

@rfcbot fcp merge

[lcnr]

@rfcbot ping

[lcnr]

@rfcbot fcp merge

[lcnr]

rfcbot needs explicit labels and otherwise just silently fails apparently?

@rfcbot fcp merge

[lcnr]

tragic, maybe with a final-comment-period and disposition-merge label as well

@rfcbot fcp merge

[lcnr]

proposed-final-comment-period :(

@rfcbot fcp merge

[lcnr]

@rfcbot poll test

[lcnr]

@rfcbot poll types test

[rfcbot]

Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @compiler-errors
• [x] @jackh726
• [x] @lcnr
• [x] @nikomatsakis
• [x] @oli-obk
• [x] @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

Team member @lcnr has asked teams: T-types, for consensus on:

test

• [x] @compiler-errors
• [x] @jackh726
• [x] @lcnr
• [ ] @nikomatsakis
• [x] @oli-obk
• [x] @spastorino

[rfcbot]

Team member @lcnr has asked teams: T-types, for consensus on:

test

[compiler-errors]

other Types Team members depending on interest.

You already know that I'm interested :smiley:

[spastorino]

other Types Team members depending on interest.

I'm interested too :)

[cjgillot]

other Types Team members depending on interest.

Do you accept out of types team also? I'd be interested.

[jackh726]

other Types Team members depending on interest.

Do you accept out of types team also? I'd be interested.

Of course :)

[BoxyUwU]

I'd also be interested in helping with this

[nikomatsakis]

@rfcbot reviewed

[vincenzopalazzo]

Looks like to have my interest too :)

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

psst @lcnr, I wasn't able to add the final-comment-period label, please do so.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

psst @lcnr, I wasn't able to add the finished-final-comment-period label, please do so.

[jackh726]

Closing as accepted 🙂