Compiler panic when matching on a reference to an enum with an unsized variant IF the field isn't being used

[SnirkImmington]

The compiler panics when matching on a reference to an enum containing a variant which is unsized IF the variable isn't being named.

Code

I tried this code on the playground and my local machine, on stable and nightly compilers:

pub enum UnsizedEnum {
    Variant([i32]) // Variant holding an unsized type
}

impl FnOnceWrapper {
    fn foo(&self) { // Function taking an &UnsizedEnum
        match self { // Some match on self (can use match *self as well)
            &UnsizedEnum::Variant(_) => // Variable isn't used
            println!("Shouldn't compile anyway?")
        }
    }
}

error: internal compiler error: ../src/librustc_trans/type_of.rs:166: Unexpected tail in unsized_info_ty: registry::types::RegistryData for ty=registry::types::RegistryData
Playpen link: http://is.gd/oY6R8Y

What should happen

The compiler should be emitting the same error as when the variable is named, I guess:

<anon>:8:34: 8:35 error: the trait bound `[i32]: std::marker::Sized` is not satisfied [E0277]
<anon>:8             UnsizedEnum::Variant(v) => 
                                          ^
<anon>:8:34: 8:35 help: see the detailed explanation for E0277
<anon>:8:34: 8:35 note: `[i32]` does not have a constant size known at compile-time
<anon>:8:34: 8:35 note: all local variables must have a statically known size
error: aborting due to previous error
playpen: application terminated with error code 101

Some examples may be compile-able if the unsized type is being ignored?

Reproduction

The bug should be reproducible on all three channels, using any unsized type in the enum variant (Variant([i32]), Variant(FnOnce()), etc.).

The variable must be _ (ignored) - a variable named _v will trigger the regular error.

A function with an owned self - fn foo(self) { match self { ... } } - does not cause the bug (it issues a regular error).

Using different matching schemes, i.e. match *self { Variant(ref _) => ... }, also caused the bug.

Replacing the enum variant with a sized type, such as Variant([i32; 5]) causes the code to compile.

Backtrace

In addition to the ones available on the playground, here's the log of my machine compiling my code:

error: internal compiler error: ../src/librustc_trans/type_of.rs:166: Unexpected tail in unsized_info_ty: BadEnum for ty=BadEnum
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', ../src/libsyntax/errors/mod.rs:576
stack backtrace:
   1:     0x7f5225112610 - std::sys::backtrace::tracing::imp::write::h9fb600083204ae7f
   2:     0x7f522511fd5b - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::hca543c34f11229ac
   3:     0x7f522511f8fc - std::panicking::default_hook::hc2c969e7453d080c
   4:     0x7f52250e528f - std::sys_common::unwind::begin_unwind_inner::h30e12d15ce2b2e25
   5:     0x7f52207211c7 - std::sys_common::unwind::begin_unwind::h24c4c0fa2cfe995a
   6:     0x7f5220720ff5 - syntax::errors::Handler::bug::h4846e60601033e50
   7:     0x7f52217d43f2 - rustc::session::opt_span_bug_fmt::_$u7b$$u7b$closure$u7d$$u7d$::hf0fb5697f8f25f40
   8:     0x7f52217d4282 - rustc::session::opt_span_bug_fmt::hc581ba88c4e2ec53
   9:     0x7f52217ec086 - rustc::session::bug_fmt::had96c08cb43bd8a1
  10:     0x7f5223d42ba5 - rustc_trans::type_of::unsized_info_ty::hce316b0f61e418ac
  11:     0x7f5223c1ed00 - rustc_trans::type_of::in_memory_type_of::h97b017bde8fe1e03
  12:     0x7f5223c11d51 - rustc_trans::abi::FnType::unadjusted::_$u7b$$u7b$closure$u7d$$u7d$::h70131b4b2d0cfbee
  13:     0x7f5223c0f6ab - rustc_trans::abi::FnType::unadjusted::hca5902507eb050fc
  14:     0x7f5223c1e79e - rustc_trans::type_of::in_memory_type_of::h97b017bde8fe1e03
  15:     0x7f5223c86533 - rustc_trans::callee::get_fn::h691a55e881985779
  16:     0x7f5223c29d60 - rustc_trans::callee::Callee::def::ha169529fef0048b5
  17:     0x7f5223c54552 - rustc_trans::base::trans_item::hdc785ae68a9e6500
  18:     0x7f5223c6decb - _<base..TransItemsWithinModVisitor<'a, 'tcx> as rustc..hir..intravisit..Visitor<'v>>::visit_item::h22c1c36dec64effa
  19:     0x7f5223c6bce7 - rustc::hir::intravisit::walk_item::he78478ac5852ebcf
  20:     0x7f5223c5cabf - rustc_trans::base::trans_crate::h6ed1dbd6e572a8c2
  21:     0x7f52256776ff - rustc_driver::driver::phase_4_translate_to_llvm::hd7579aae98641824
  22:     0x7f5225675d8f - rustc_driver::driver::compile_input::_$u7b$$u7b$closure$u7d$$u7d$::he3c6b6ab9afe28dd
  23:     0x7f5225672630 - rustc_driver::driver::phase_3_run_analysis_passes::_$u7b$$u7b$closure$u7d$$u7d$::h06c776ef4d1c70b6
  24:     0x7f522566bf5e - rustc::ty::context::TyCtxt::create_and_enter::hb0e0e916c7274a64
  25:     0x7f522563e90d - rustc_driver::driver::compile_input::h0629572e6f316b31
  26:     0x7f522561f53c - rustc_driver::run_compiler::h8902aebf8b1849a8
  27:     0x7f522561cc41 - std::sys_common::unwind::try::try_fn::h4c74456035d0fcc7
  28:     0x7f522510fdeb - __rust_try
  29:     0x7f522510fd7d - std::sys_common::unwind::inner_try::h47a4d9cd4a369dcd
  30:     0x7f522561d48a - _<F as std..boxed..FnBox<A>>::call_box::h27f542a39f1d61ef
  31:     0x7f522511def4 - std::sys::thread::Thread::new::thread_start::h6f266e069bf4ec2b
  32:     0x7f521cea5423 - start_thread
  33:     0x7f5224d7ccbc - clone
  34:                0x0 - <unknown>

error: Could not compile `bug-report`.

To learn more, run the command again with --verbose.

$ rustc --version --verbose

rustc 1.10.0-nightly (8da2bcac5 2016-04-28)
binary: rustc
commit-hash: 8da2bcac5db1e091b90cceb19d0496f0f7501c88
commit-date: 2016-04-28
host: x86_64-unknown-linux-gnu
release: 1.10.0-nightly

Sorry if this is a duplicate report, I saw a couple that looked similar but they had both been closed.
(update: added rustc version with --verbose

[jonas-schievink]

Duplicate of #32765

[SnirkImmington]

@jonas-schievink That report doesn't mention hidden values, and it's about trait objects.

[jonas-schievink]

The issue is that the compiler doesn't properly handle unsized enums (which can be created by putting a trait object or a slice directly in them), which can result in errors when you just look at them sharply. All ICEs of this sort have the same message, indicating that it's the same issue: "Unexpected tail in unsized_info_ty". So this actually also seems like a duplicate of #16812

[apasel422]

Closing as duplicate.