Or-pattern example causes Internal Compiler Error

[cr1901]

Code

The following code snippet demonstrating or-patterns crashes the nightly compiler on the Playground as of 2-2-2020.

#![feature(or_patterns)]

enum MyEnum {
    FirstCase(u8),
    OtherCase(u16),
}

fn my_fn(x @ (MyEnum::FirstCase(_) | MyEnum::OtherCase(_)): MyEnum) {}

(Playground)

Error

error: internal compiler error: match pairs [MatchPair { place: _1, pattern: Pat { ty: MyEnum, span: src/lib.rs:8:15: 8:58, kind: Or { pats: [Pat { ty: MyEnum, span: src/lib.rs:8:15: 8:35, kind: Variant { adt_def: MyEnum, substs: [], variant_index: 0, subpatterns: [FieldPat { field: field[0], pattern: Pat { ty: u8, span: src/lib.rs:8:33: 8:34, kind: Wild } }] } }, Pat { ty: MyEnum, span: src/lib.rs:8:38: 8:58, kind: Variant { adt_def: MyEnum, substs: [], variant_index: 1, subpatterns: [FieldPat { field: field[0], pattern: Pat { ty: u16, span: src/lib.rs:8:56: 8:57, kind: Wild } }] } }] } } }] remaining after simplifying irrefutable pattern
 --> src/lib.rs:8:15
  |
8 | fn my_fn(x @ (MyEnum::FirstCase(_) | MyEnum::OtherCase(_)): MyEnum) {}
  |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:357:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

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.42.0-nightly (13db6501c 2020-02-01) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: could not compile `playground`.

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

Other Information

I understand that or-patterns are incomplete feature, thus errors are expected. But I was told to report this anyway (cc: @estebank).

It's not convenient for me to test locally right now; is it possible to get a backtrace on the Playground?

[jonas-schievink]

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:357:17
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1052
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1428
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
  12: std::panicking::begin_panic
  13: <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop
  14: core::ptr::drop_in_place
  15: core::ptr::drop_in_place
  16: core::ptr::drop_in_place
  17: rustc_interface::interface::run_compiler_in_existing_thread_pool
  18: scoped_tls::ScopedKey<T>::set
  19: syntax::attr::with_globals

[Centril]

@matthewjasper You might want to throw this into your PR (#67668) as a test case.

[cr1901]

Would appreciate clarification here:

I don't believe pattern binding with or-patterns within function arguments (x @ (MyEnum::FirstCase(_) | MyEnum::OtherCase(_))) is semantically different from a pattern consisting of only the variable name (x).

However, it's semantically valid code, and can be used as a contrived example to demonstrate exhaustive pattern matching. Which is how I found this ICE in the first place.

[Centril]

@cr1901 It's semantically equivalent, but it results in different code-paths in the compiler. I'm quite sure that #67668 will fix this though as it seems more or less like a dupe of #67514 (but different enough that a test case should maybe be added). The MIR parts of or-patterns have simply not been implemented yet, but we're pretty close.