internal compiler error: no entry found for key

[dwrensha]

I'm seeing an internal compiler error on the following input (found by fuzz-rustc):

async fn a(x | s: String) {}
fn main() {}

$ rustc --edition=2018 main.rs 
error: an or-pattern parameter must be wrapped in parenthesis
 --> main.rs:1:12
  |
1 | async fn a(x | s: String) {}
  |            ^^^^^ help: wrap the pattern in parenthesis: `(x | s)`

error[E0408]: variable `x` is not bound in all patterns
 --> main.rs:1:16
  |
1 | async fn a(x | s: String) {}
  |            -   ^ pattern doesn't bind `x`
  |            |
  |            variable not in all patterns

error[E0408]: variable `s` is not bound in all patterns
 --> main.rs:1:12
  |
1 | async fn a(x | s: String) {}
  |            ^   - variable not in all patterns
  |            |
  |            pattern doesn't bind `s`

thread 'rustc' panicked at 'no entry found for key', src/librustc_mir_build/build/mod.rs:343:9
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.44.0-nightly (ce93331e2 2020-04-17) running on x86_64-unknown-linux-gnu

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0408`.

[dwrensha]

Report from cargo-bisect-rustc:

searched nightlies: from nightly-2020-02-10 to nightly-2020-04-18
regressed nightly: nightly-2020-02-16
searched commits: from 433aae9 to 61d9231
regressed commit: 19288dd

[jonas-schievink]

cc @matthewjasper

Panic happens here:

rust/src/librustc_mir_build/build/mod.rs

Lines 342 to 344 in 52fa23a

	fn var_local_id(&self, id: hir::HirId, for_guard: ForGuard) -> Local {
	self.var_indices[&id].local_id(for_guard)
	}

[estebank]

I think that or-patterns should be disallowed in arguments to begin with.

[Mark-Simulacrum]

@estebank hm, so at least in principle it seems quite reasonable -- e.g., I might want something like Result<u32, u32> to be taken as Ok(x) | Err(x), right?

I don't see why we'd want such an arbitrary restriction; can you elaborate?

[estebank]

@Mark-Simulacrum you're right, I hadn't thought of the possibility of different enough variants having the same type binding.

[LeSeulArtichaut]

Assigning P-low as discussed as part of the Prioritization-WG process