Repository navigation
ICE when using exhaustive_patterns without never_type #51221
Description
~$ cat a.rs
#![feature(exhaustive_patterns)]
fn main() {
enum Void {}
let a: Option<Void> = None;
let None = a;
}
~$ rustc +nightly a.rs
error: internal compiler error: librustc_mir/build/matches/mod.rs:225: match pairs [MatchPair { place: _1, pattern: Pattern { ty: std::option::Option<main::Void>, span: a.rs:5:9: 5:13, kind: Variant { adt_def: std::option::Option, substs: [main::Void], variant_index: 0, subpatterns: [] } }, slice_len_checked: false }] remaining after simplifying irrefutable pattern
--> a.rs:5:9
|
5 | let None = a;
| ^^^^
thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:499:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to previous error
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: rustc 1.28.0-nightly (524ad9b9e 2018-05-29) running on x86_64-apple-darwin
👉 101This compiles successfully with #![feature(exhaustive_patterns,never_type)]. It's possible that this regressed when the two features were separated. It's also possible that stabilizing never_type first will make this issue moot.
Activity
hellow554 commentedon May 13, 2019
I'm very surprised that this is still open. @jonas-schievink can you add the I-nomiated flag please, if you think it's appropriate here?
@rustbot modify labels: T-compiler C-Bug
jonas-schievink commentedon May 13, 2019
This only seems to occur with nightly features enabled, so I'm not sure it's supposed to be nominated. I'll mention it in the tracking issue though.
Rollup merge of rust-lang#62405 - hellow554:patch-1, r=varkor