"or-patterns should have already been handled" when using feature(or_patterns)

[Zenithsiz]

When using the or_patterns feature, attempting to match on a tuple creates a compiler panic.

The following code causes the panic.

#![feature(or_patterns)]

fn f(s: &str, num: usize) {
	match (s, num) {
		("", 0) | ("a" | "b", 1) => (),
		
		_ => ()
	}
}

(Also available at the playground)

This occurs both on the playground and on my local machine on a previous version (details below).

Meta

Rust version from the playground:

1.45.0-nightly
(2020-05-26 5239f5c)

Local version:

rustc 1.45.0-nightly (a74d186 2020-05-14)
binary: rustc
commit-hash: a74d186
commit-date: 2020-05-14
host: x86_64-pc-windows-msvc
release: 1.45.0-nightly
LLVM version: 9.0

Playground backtrace:

  Compiling playground v0.0.1 (/playground)
error: internal compiler error: src/librustc_mir_build/build/matches/test.rs:70: or-patterns should have already been handled

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:907:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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.45.0-nightly (5239f5c57 2020-05-26) running on x86_64-unknown-linux-gnu

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

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

error: aborting due to previous error

error: could not compile `playground`.

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

Local backtrace:

error: internal compiler error: src\librustc_mir_build\build\matches\test.rs:70: or-patterns should have already been handled

thread 'rustc' panicked at 'Box<Any>', src\librustc_errors\lib.rs:907:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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.45.0-nightly (a74d1862d 2020-05-14) running on x86_64-pc-windows-msvc

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type cdylib

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

EDIT: Added local machine backtrace too

[OddCoincidence]

It looks like the problem is here in sort_candidates. The call to self.test seems to rely on the invariant that the match pairs have been fully simplified at this point, but or_patterns are a special case and can still show up here.

rust/src/librustc_mir_build/build/matches/test.rs

Lines 684 to 695 in 5d39f1f

	(&TestKind::Eq { .. } | &TestKind::Len { .. }, _) => {
	// These are all binary tests.
	//
	// FIXME(#29623) we can be more clever here
	let pattern_test = self.test(&match_pair);
	if pattern_test.kind == test.kind {
	self.candidate_without_match_pair(match_pair_index, candidate);
	Some(0)
	} else {
	None
	}
	}

[vertexclique]

Reproducible with recent nightlies too: note: rustc 1.48.0-nightly (7f7a1cbfd 2020-09-27) running on x86_64-apple-darwin:

error: internal compiler error: compiler/rustc_mir_build/src/build/matches/test.rs:69:35: or-patterns should have already been handled

thread 'rustc' panicked at 'Box<Any>', compiler/rustc_errors/src/lib.rs:945:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.48.0-nightly (7f7a1cbfd 2020-09-27) running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental -C target-cpu=haswell --crate-type lib

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

Triggered by more than 3 pattern condition with this compiler version.

[mark-i-m]

I would have assumed that the implementation merely desugars into a bunch of top-level or-patterns. Is that not the case? Why are tuples special cased?

If it isn't too involved, I could take a crack at this with some guidance... very much want to see this over the finish line.