# "Chalkify rustc" roadmap planning

## Four mostly-orthogonal efforts

### Library-ification: type library

Summary: The effort to extract out a `rustc_type_ir` that will eventually be shared with Chalk and potentially can be used for other projects too.

* rustc "implementation" seems blocked on assoc. type variance
* took `TyCtxt`, `TyKind` and moved into a separate crate in rustc
* made it generic (over an `Interner` trait)
* so many things that depend on Ty to be covariant
* https://github.com/jackh726/rust/tree/type-interner
* Design question: What do we do with `Param` and early bound distinctions?
* Option 1: Add these to Chalk
* Option 2: Remove these from rustc
* Option 3: Always replace with placeholders when calling Chalk (done currently)
* Some small remaining type-level differences
* Generators
* `Alias`
* relevant: https://github.com/rust-lang/compiler-team/issues/504

### Library-ification: chalk itself

Summary: Making Chalk itself a fully-suitable Rust trait solver. Does not necessarily require integration in rustc to be useful in e.g. rust-analyzer.

* Extending chalk to cover things rustc does
* const generics (this is somewhat supported)
* const eval
* specialization
* `Copy`/`Clone` now in std
* Some bugs with existing implementation(s)
* Implied bounds in recursive solver
* Associated type normalization in SLG
* "Typecheck in-progress" closures
* https://github.com/rust-lang/chalk/issues/688
* Need to figure out region constraints story
* Heavily influenced by Niko's subtyping work
* So far, zero performance work

### Query-based evaluation in rustc

Summary: Converting rustc trait solving to use only canonical queries, instead of `FulfillmentContext`. Better for incremental and a more Chalk-like approach.

* Highly likely to impact diagnostics: Canonical queries lose span info
* Very recent experimenation: https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/attaching.20lints.20to.20successful.20selections/near/279036796
* Question: How do we "trace" what caused an obligation to fail?
* Question: What about when obligations don't fail, but need something special (lints, features)?

### Rewriting a new trait solver in rustc

Summary: Starting fresh with `a-mir-formality` design in mind, without needing to worry about extracting out a type library.

* "MIR for traits"
* unified evaluation + fulfillment cx pathway
* no more winnowing!
* associated type handling
* limited notion of types (no implication, no foralls, etc)
* limited set of goals
* no implication, no foralls, etc
* region/lifetime handling

## What are the goals here?

### What features or bugs do we want to solve *for rustc*?

* https://github.com/rust-lang/rust/issues/71723
* PR #92449, auto traits + something + generators
* PR #94238, Erase trivial caller-bounds when typechecking MIR after optimizations
* https://github.com/rust-lang/rust/issues/25860 -- soundness hole
* https://github.com/rust-lang/rust/issues/63033
* PR #89056
* GATs, `for<'a> T: 'a` etc

### In what ways and to what extent do we want to support the community?

*I would say rust-analyzer, but that's under the Rust Project now...*

* Formal verifiers?
* Static analyzers?
* Alternative compilers?

## What bandwidth do we have? And how do we prioritize the work?

* How can we be better at soliciting/accepting help?
* Sprints worked well when tasks were relatively small and self-contained

# Questions

# Topics discussed in meeting

## What are our goals

* Overcome many limitations and unsoundnesses in rustc
* Produce a reusable, shared library for rust-analyzer, rustc, and others that can perform trait solving and (eventually) type checking
* Provide a rigorous definition of Rust's type system writ large (i.e., including trait solving, type checking, and borrow checking)