Implement RFC 2338, "Type alias enum variants"

[alexreg]

This PR implements RFC 2338, allowing one to write code like the following.

#![feature(type_alias_enum_variants)]

enum Foo {
    Bar(i32),
    Baz { i: i32 },
}

type Alias = Foo;

fn main() {
    let t = Alias::Bar(0);
    let t = Alias::Baz { i: 0 };
    match t {
        Alias::Bar(_i) => {}
        Alias::Baz { i: _i } => {}
    }
}

Since Self can be considered a type alias in this context, it also enables using Self::Variant as both a constructor and pattern.

Fixes issues #56199 and #56611.

N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the tracking issue), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible.

Option::<u8>::None; // OK
Option::None::<u8>; // OK, but lint in near future (hard error next edition?)
Alias::<u8>::None; // OK
Alias::None::<u8>; // Error

I do not know if this will need an FCP, but let's start one if so.

[alexreg]

The tricky part of handling type parameters is still to be done, but basic cases are working already. Any advice on this expanding on your previous comment would be appreciated, @petrochenkov. (Hope you don't mind I r?ed you, as well.)

[petrochenkov]

Everything about generic arguments should be in instantiate_value_path (at least for values).
Can't say more, last time I looked at that code a couple of years ago and it was rewritten since then at least twice, IIRC (by eddyb and varkor).

[alexreg]

Big push coming up... I should be able to finish this tomorrow.

[alexreg]

Ready for review now, @petrochenkov. :-)

[djc]

Awesome that you managed to implement this!

I'm still a bit concerned about the handling of type arguments, since the implementation now diverges from the very explicit decision made in the RFC. @petrochenkov registered his concern then, too, but I'm surprised that the implementation now diverges from the spec as laid down in the RFC.

[eddyb]

@djc I believe the RFC as accepted is generally unimplementable, it seems that was an oversight during accepting it.

EDIT: to expand a bit on that: Alias::Variant is merely sugar for <T>::Variant, given the pre-existing rules for type-qualified paths, and so the implementation must be able to handle any type (not just aliases) that is semantically an enum, as if variants were associated constants.

That means that if type parameters are involved, Alias::Variant may be sugar for <Alias<_>>::Variant resolving to <Enum<_>>::Variant or even <Alias>::Variant resolving to <Enum<SpecificType>>::Variant.

At the point where you can introduce any new semantics, you already have a type with its parameters applied, and all you can do is use them in conjunction with the variant. Unless you want to allow parameters to be specified twice, you can't allow parameters on the variant as well.

I believe this problem with the RFC might've resulted from missing the fact that Alias::Variant already can successfully compile, if Variant is an associated constant or method.
Therefore, it has pre-existing semantics (i.e. type-qualified path) that can't be ignored.

[petrochenkov]

@bors r+

[bors]

📌 Commit a4fa7ef has been approved by petrochenkov

[alexreg]

Thanks for helping get this past the post, @petrochenkov. :-)

[bors]

⌛ Testing commit a4fa7ef with merge 5918318...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing 5918318 to master...

[rust-highfive]

📣 Toolstate changed by #56225!

Tested on commit 5918318.
Direct link to PR: #56225

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 rls on windows: test-pass → build-fail (cc @nrc @Xanewok, @rust-lang/infra).
💔 rls on linux: test-pass → build-fail (cc @nrc @Xanewok, @rust-lang/infra).