Stream: t-compiler/rust-analyzer

Topic: Moving Ty to be closer to chalk's TyKind

Lukas Wirth (Feb 28 2021 at 22:30, on Zulip):

I've been looking at our Ty::Infer(InferTy) variant to bring it closer to chalks representation InferenceVar(InferenceVar, TyVariableKind) and noticed that our InferTy basically has 4 variable kinds unlike chalk which has 3. We have an extra MaybeNever variant:

pub enum InferTy {

If we were to switch over to chalk's typesystem one day we would lose this information if I'm not mistaken right? Is this something that should actually go into chalk?

detrumi (Feb 28 2021 at 22:43, on Zulip):

Chalk does support the never type, and rust's InferTy doesn't contain a Never variant, so I don't think a variant needs to be added in chalk

detrumi (Feb 28 2021 at 22:44, on Zulip):

Unless MaybeNever is something RA added for better IDE support?

Lukas Wirth (Feb 28 2021 at 22:46, on Zulip):

From what I've seen it's used to specify type inference fallback to use never instead of the unit type in RA

detrumi (Feb 28 2021 at 22:48, on Zulip):

Chalk and rustc use a TyKind::Never type instead, but yeah then you wouldn't have a TypeVarId. But I don't think that's actually needed anywhere

Lukas Wirth (Feb 28 2021 at 23:16, on Zulip):

I see, figured it's gonna be like that. I imagine the problem lies in how type inference is structured in RA then, Florian should know. I haven't looked too much into how type inference in RA works(or rather that much in general either).

Florian Diebold (Mar 01 2021 at 08:25, on Zulip):

I'm pretty sure rustc has a similar mechanism? let me check

Florian Diebold (Mar 01 2021 at 08:31, on Zulip):

ah, rustc does this with a flag in a separate data structure indicating that the type variable is diverging

Florian Diebold (Mar 01 2021 at 08:31, on Zulip):

Florian Diebold (Mar 01 2021 at 08:32, on Zulip):

that would probably be a good refactoring, and we'll want to keep additional information on type variables (like the origin) anyway

Lukas Wirth (Mar 01 2021 at 10:27, on Zulip):

Ah I see, we would store this in the InferenceTable then if i see this right?

Florian Diebold (Mar 01 2021 at 10:32, on Zulip):

I think it needs to be a separate table (keyed by variable ID)

Lukas Wirth (Mar 01 2021 at 10:35, on Zulip):

sorrry, meant it as in whether the extra table should be in InferenceTable, since InferenceTable needs it for the fallback.

Lukas Wirth (Mar 01 2021 at 10:35, on Zulip):

or pass it by ref on each call where required

Florian Diebold (Mar 01 2021 at 10:51, on Zulip):

aah right sorry, yeah it makes sense to put it there

Last update: Jul 27 2021 at 20:30UTC