Description
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