@matklad you pinged me about the possibility of libraryfying match checking. I think this is quite feasible!
exhaustiveness checking specifically is a very independent bit of code. It uses only Ty and a crate-local Pat enum
AFAIK it also uses a single query, namely checking for type inhabitedness
I know that there Ty is in the process of being librarified. Are there also plans to share the representation of patterns at all?
What kind of knowledge does it require about
Ty? Does it care about specific
TyKinds at all?
Yeah it pattern-matches on
TyKinds a ton
Ah I guess another tricky bit is constants. There's a pass that converts constants into the corresponding patterns and rust-analyzer might need that for completeness. But that taps into constant evaluation which sounds like a can of worms
Seems like constant evaluation can be exctacted relatively easy, no?
Bascially, the match checking code can be parametrized over
TyKind feels more worrisome to me. Can the pattern-matching be moved to the caller? Ie, if it already has an internal IR of patterns, can we reformulate the code such that it's the caller who lowers
Ty to patterns?
TyKinds don't get interpreted as patterns. They're pattern-matched throughout the code to make all sorts of decisions :/
But pattern-matching TyKind should be fine once Ty is extracted to a shared library between rustc and chalk, right?
So I guess it's better to re-visit this topic once types are extracted...
Cool, let's do that
@Florian Diebold what's the way for me to educate myself about the shared types library?
I am curious about bunch of things: do types carry identity? are they just values? how the memory management works? does "code changes over time" aspect of rust-analyzer affects the types?
FWIW here's what chalk currently uses https://docs.rs/chalk-ir/0.68.0/chalk_ir/enum.TyKind.html . Ty itself is parameterized over an interner
@matklad I don't know many details either, there's a hackmd somewhere, but my understanding is that it's mostly supposed to look like chalk_ir
https://github.com/rust-lang/wg-traits/issues/16 is a good place to start I guess
We could also consider fallible implementation instead of bugging out with panic https://github.com/rust-analyzer/rust-analyzer/pull/9105#discussion_r644656085
we do want to bug out in debug builds, for actual bugs. For librarification we could maybe just control it with a cargo feature
What's the scope of what rust-analyzer needs?
Eventually, we need everything, so the question is rather "what's the most natural scope to create a boundary between the libraries"