Stream: t-compiler/rust-analyzer

Topic: Type aliases in inlay hints

Kirill Bulatov (May 07 2021 at 11:15, on Zulip):


One of those features I want to do, but have no clues how, due to zero knowledge on how things are supposed to work below hir.
Could somebody give me code pointers and high-level explanations on how to tackle this?

I believe, the end user API has to be somewhere on the, where all type_of_* calls should return type aliases instead of a "raw" type as we do now?

It feels like I need to store the alias info into a cache(?) during lowering(???) along with their visibility and look it up before returning a type_of_*?
What about funny cases generic type aliases?

Florian Diebold (May 07 2021 at 11:28, on Zulip):

this is quite non-trivial :grimacing: the first problem is representing this at all. There's currently no way of representing an unresolved type alias as a type, so the two options are a) add it to the Chalk type system, or b) introduce our own intermediate type representation that we transform Chalk types from and back.

Florian Diebold (May 07 2021 at 11:29, on Zulip):

a) is something that's actually been considered (basically it would mean implementing "lazy normalization" for type aliases, instead of the eager lowering we have right now), but it's obviously a somewhat deep change in the type system

Florian Diebold (May 07 2021 at 11:31, on Zulip):

b) is something I've also wanted to do for other reasons and even started, but stopped for various reasons. I still think it's probably a good idea though. But it would still leave the problem how to thread the information that something was originally a type alias through the actual type system

Florian Diebold (May 07 2021 at 11:36, on Zulip):

(to expand on b a bit more, what I'm thinking of is something that's close to how types are written in surface rust (so like TypeRef in that regard), but with resolved IDs instead of names)

Florian Diebold (May 07 2021 at 11:40, on Zulip):

here are some slightly more complicated cases to consider:

let x = Some(foo());
let _ = identity(foo());
match x { Some(z) => {} }
let _ = x.unwrap();
let _ = foo() + 2;
Florian Diebold (May 07 2021 at 11:42, on Zulip):
let _ = if true { foo() } else { 1 };
Lukas Wirth (May 07 2021 at 11:56, on Zulip):

We have an issue for this right? Might be good to drop this topic in a comment there(or make an issue about this if we haven't yet)

Lukas Wirth (May 07 2021 at 11:57, on Zulip):

Florian Diebold said:

let _ = if true { foo() } else { 1 };

This one looks like a fun one :grimacing:

Florian Diebold (May 07 2021 at 11:59, on Zulip):

yeah, I think we do

Florian Diebold (May 07 2021 at 12:00, on Zulip):

Florian Diebold (May 07 2021 at 12:05, on Zulip):

I wrote there

I personally don't think we should treat type aliases as a separate type

but Niko has since mentioned maybe wanting to do that anyway for other reasons, hence why I mentioned it as possibility a) above

Kirill Bulatov (May 07 2021 at 12:42, on Zulip):

Right, so even if you deferred doing this now and it all goes down to the type level, looks like I'm shooting the moon here :smile:
Thank you for elaborating on this again, I'll link this topic into the issue, as suggested.

Last update: Jul 27 2021 at 22:15UTC