Tracking issue for RFC 2338, "Type alias enum variants"

[Centril]

This is a tracking issue for the RFC "Type alias enum variants" (rust-lang/rfcs#2338).

Steps:

• Implement the RFC (Implement RFC 2338, "Type alias enum variants" #56225)
• Adjust documentation (see instructions on forge)
• Stabilization PR (Stabilize type_alias_enum_variants in Rust 1.37.0 #61682)

Unresolved questions:

• Decide how to resolve in case of ambiguities between associate types and variants. (Currently low-priority resolution for variants.) See Implement RFC 2338, "Type alias enum variants" #56225 (comment). Resolved in favour of high-priority resolution with High priority resolutions for associated variants #57501.

[djc]

I'd like to try implementing this. Since there was a previous implementation attempt in #31179, I can probably start off of that, but mentoring instructions would be quite welcome.

[petrochenkov]

Short instructions:

• Find a place where associated types are resolved to their definitions (probably fn associated_path_def_to_ty) and add high-priority resolution to variant definitions.
• Find a place where associated values are resolved to their definitions (probably fn resolve_ufcs) and add high-priority resolution to variant definitions.
• Try to apply the "argument transfer" scheme (Type::AssocItem<Args> -> Type<Args>::AssocItem) to generic arguments of associated items if they resolve to variants. This can meet complications because this is not something that can (or should) be done naturally, as I previously described.

[earthengine]

I have a specific concern on this. Right now, every concrete type name contains information of its component type names, making it very easy to have the name length being explode. Introducing something that making this issue worse may not be a good idea if we haven't get the type names shorted.

Here is an example of how bad this problem can be.

Internally, a type should contain all information to identify itself. But it is not necessary appear in the name, especially when the name is too long, because type names areintended to be read by human, and no one will read a name with a million chars. On the other hand, computer code will feel more comfortable to manipulating referencing structures. So by limiting the type name size we wouldn't lose anything.

To making things worse, I just figured out that the length of a single type is not the issue I experienced. The problem is that there are too many (and too long) type names being generated, and so exceeded the compiler limit. This is why it is getting worse when I extract methods as it forces the compiler to generate more types.

This RFC, once implemented, will add much more types to the system, so please measure a typical closure-heavy-and-impl-trait-heavy program, to see how bad this problem is. It would also be good to allow the compiler to generate statistics of the types it generates, so we can keep tracking this.

[alexreg]

@djc Did you manage to make any headway on the implementation of this?

[djc]

@alexreg no, not yet. Feel free to move forward if you want to take a crack at it!

[alexreg]

Too busy right now, I'm afraid. I'd need more detailed mentoring instructions too, as too many of these concepts are foreign to me... best someone else tackles it.

[pravic]

It was already implemented. Why not to reopen the previous PR?

[alexreg]

@pravic Where’s that PR?

[pravic]

#31179

[alexreg]

Thanks.