rustc trait system rewrite initiative #58
Description
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 better1 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
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.
Footnotes
-
currently different
FnCtxtandObligationCtxtdo not share a cache forfulfilland also don't share it with mir borrowck. ↩