Stream: t-compiler/rust-analyzer

Topic: libraryfying match checking?


Nadrieril (Jun 01 2021 at 22:02, on Zulip):

@matklad you pinged me about the possibility of libraryfying match checking. I think this is quite feasible!

Nadrieril (Jun 01 2021 at 22:03, on Zulip):

exhaustiveness checking specifically is a very independent bit of code. It uses only Ty and a crate-local Pat enum

Nadrieril (Jun 01 2021 at 22:03, on Zulip):

AFAIK it also uses a single query, namely checking for type inhabitedness

Nadrieril (Jun 01 2021 at 22:04, on Zulip):

I know that there Ty is in the process of being librarified. Are there also plans to share the representation of patterns at all?

Jonas Schievink [he/him] (Jun 01 2021 at 22:31, on Zulip):

What kind of knowledge does it require about Ty? Does it care about specific TyKinds at all?

Nadrieril (Jun 01 2021 at 23:08, on Zulip):

Yeah it pattern-matches on TyKinds a ton

Nadrieril (Jun 01 2021 at 23:14, on Zulip):

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

matklad (Jun 02 2021 at 08:48, on Zulip):

Seems like constant evaluation can be exctacted relatively easy, no?

Bascially, the match checking code can be parametrized over eval function

matklad (Jun 02 2021 at 08:49, on Zulip):

They 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?

Nadrieril (Jun 02 2021 at 09:20, on Zulip):

TyKinds don't get interpreted as patterns. They're pattern-matched throughout the code to make all sorts of decisions :/

Nadrieril (Jun 02 2021 at 09:28, on Zulip):

But pattern-matching TyKind should be fine once Ty is extracted to a shared library between rustc and chalk, right?

matklad (Jun 02 2021 at 09:28, on Zulip):

Right!

matklad (Jun 02 2021 at 09:29, on Zulip):

So I guess it's better to re-visit this topic once types are extracted...

Nadrieril (Jun 02 2021 at 09:30, on Zulip):

Cool, let's do that

matklad (Jun 02 2021 at 09:31, on Zulip):

@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?

Nadrieril (Jun 02 2021 at 09:33, on Zulip):

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

Florian Diebold (Jun 02 2021 at 09:54, on Zulip):

@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

Florian Diebold (Jun 02 2021 at 10:03, on Zulip):

https://github.com/rust-lang/wg-traits/issues/16 is a good place to start I guess

Dawer (Jun 03 2021 at 11:55, on Zulip):

We could also consider fallible implementation instead of bugging out with panic https://github.com/rust-analyzer/rust-analyzer/pull/9105#discussion_r644656085

Florian Diebold (Jun 03 2021 at 12:04, on Zulip):

we do want to bug out in debug builds, for actual bugs. For librarification we could maybe just control it with a cargo feature

Nadrieril (Jun 12 2021 at 00:45, on Zulip):

What's the scope of what rust-analyzer needs?

matklad (Jun 12 2021 at 12:15, on Zulip):

Eventually, we need everything, so the question is rather "what's the most natural scope to create a boundary between the libraries"

Last update: Jul 24 2021 at 20:45UTC