Using a type alias on an enum prevents using that enum's variants as the values for other enum variants, with "error: constant evaluation error: unresolved path in constant expression"

[bstrie]

Here is a program that works just fine:

enum Foo {
    Foofoo = 0
}

enum Bar {
    Barbar = Foo::Foofoo as isize
}

fn main() {}

Here is that same program with a seemingly spurious error:

enum Foo {
    Foofoo = 0
}

type Qux = Foo;

enum Bar {
    Barbar = Qux::Foofoo as isize
}

fn main() {}

Error:

<anon>:8:14: 8:25 error: constant evaluation error: unresolved path in constant expression [E0080]
<anon>:8     Barbar = Qux::Foofoo as isize
                      ^~~~~~~~~~~

[moretea]

Encountered this bug when using bindgen. Bindgen produces the following code for a C enum:

pub enum Enum_Unnamed1 {
    SDL_AUDIO_STOPPED = 0,
    SDL_AUDIO_PLAYING = 1,
    SDL_AUDIO_PAUSED = 2,
}
pub type SDL_AudioStatus = Enum_Unnamed1;

[moretea]

This also fails when crate boundaries are crossed, see this example crate.

[arielb1]

Not sure how much of a bug this is.

[oli-obk]

@moretea the crate boundary issue is already reported here: #24469

[bstrie]

@arielb1 I understand that type does not currently serve as a 100% transparent alias, but I was under the impression that such limitations were viewed as unfortunate accidents of the current implementation rather than deliberate design choices. For what reason would this not be a bug?

[arielb1]

The confusing thing is that enum variants are not associated items - because of historical reasons we are stuck with - and therefore don't work with type (or <Type> syntax, or whatever): this is basically the same reason type does not import a tuple-like struct constructor. We may want to change this.

[nodakai]

Possible duplicate of #26264

[alexcrichton]

Ah yes, looks to be a dupe of #26264 indeed!