ICE on with #[repr(..)] for single-variant enum

[Ericson2314]

#[repr(u8)]
enum Foo {
    Foo(u8),
}

fn main() {
    match Foo::Foo(1) {
        _ => ()
    }
}

Same error on all nightly and stable:

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https:/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'assertion failed: `(left == right)` (left: `ReprInt(<anon>:1:8: 1:10, UnsignedInt(u8))`, right: `ReprAny`)', ../src/librustc/ty/layout.rs:953
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[nagisa]

cc @eddyb

[eddyb]

How does this not trigger an error?

[TimNN]

Note that adding a second variant reports no error at all (I stumbled upon this ICE as well, just now):

#[repr(u8)]
enum Foo {
    Foo(u8),
    Bar
}

Edit: this is already tracked at #31692

[TimNN]

Probably relevant from #25651:

the #[repr] attribute on data-carrying enums is intentional (e.g. to control the size of the discriminant. It's just quite rare that it's actually used.

[TimNN]

This has become a regression (probably since #34846 was merged):

The following compiles fine on stable, beta and nightly-2016-07-12 but fails on later nightlies.

#[repr(C)]
pub enum TupleSingle {
     Tuple(u8),
}

fn main() {}

[jonas-schievink]

Interestingly, it's only a regression if the enum was completely unused before. @eddyb's type layout code will be invoked for all types that are lowered down to an LLVM representation, which doesn't happen if the type is unused. This ICEs on stable, too:

#[repr(u8)]
pub enum TupleSingle {
    Tuple(u8),
}

fn main() {
    let t = TupleSingle::Tuple(0);
}

[zackmdavis]

Doesn't seem to reproduce anymore?

$ rustc --version
rustc 1.14.0-nightly (a3bc191b5 2016-10-10)
$ cat scratch.rs 
#[repr(u8)]
enum Foo {
    Foo(u8),
}

fn main() {
    match Foo::Foo(1) {
        _ => ()
    }
}
$ rustc scratch.rs 
$ echo $?
0

[TimNN]

This was fixed between nightly-2016-09-22 and nightly-2016-09-27 (Changes), more precisely this was fixed by #36151, as far as I can tell.

I'm gonna tag this as needstest so we can make sure this does not regress in future.