Change:
<ins> error[E0596]: cannot borrow `*x.1` as mutable, as it is behind a `&` reference --> $DIR/issue-61623.rs:6:19 | LL | fn f3<'a>(x: &'a ((), &'a mut ())) { |              -------------------- help: consider changing this to be a mutable reference: `&'a mut ((), &'a mut ())` LL |     f2(|| x.0, f1(x.1)) |                   ^^^ `x` is a `&` reference, so the data it refers to cannot be borrowed as mutable error[E0502]: cannot borrow `*x.1` as mutable because it is also borrowed as immutable --> $DIR/issue-61623.rs:6:19 | LL |     f2(|| x.0, f1(x.1)) |     -- -- -       ^^^ mutable borrow occurs here |     |  |  | |     |  |  first borrow occurs due to use of `x` in closure |     |  immutable borrow occurs here |     immutable borrow later used by call error: aborting due to 2 previous errors Some errors have detailed explanations: E0502, E0596. For more information about an error, try `rustc --explain E0502`. </ins>

Discussion:
I compiled the following code expecting some sort of error message. Instead, the compiler panicked unexpectedly. () errors: errors: :
Triage: Likely dupe of cc Preliminarily assigning P-high before compiler team meeting.

ICE on both and code <details<summarybacktrace: cargo run +stable build --verbose</summary</details
Likely dupe of cc

The following code causes a panic in rustc nightly and stable 2018 Edition: I do not expect this to compile, as gettree requires a mut reference, which is not provided by get. When changing gettree to , the code compiles properly. <details<summaryBacktrace</summary<preCompiling playground v0.0.1 (/playground) thread 'rustc' panicked at 'no entry found for key', stack backtrace: 0: backtrace::backtrace::libunwind::trace at 1: backtrace::backtrace::traceunsynchronized at 2: std::syscommon::backtrace::print at 3: std::syscommon::backtrace::print at 4: std::panicking::defaulthook::{{closure}} at 5: std::panicking::defaulthook at 6: rustc::util::common::panichook 7: std::panicking::rustpanicwithhook at 8: std::panicking::continuepanicfmt at 9: rustbeginunwind at 10: core::panicking::panicfmt at 11: core::option::expectfailed at 12: rustcmir::borrowcheck::pathutils::eachborrowinvolvingpath 13: rustcmir::borrowcheck::MirBorrowckCtxt::accessplace 14: <rustcmir::borrowcheck::MirBorrowckCtxt as rustcmir::dataflow::DataflowResultsConsumer::visitstatemententry 15: rustcmir::borrowcheck::domirborrowck 16: rustc::ty::context::GlobalCtxt::enterlocal 17: rustcmir::borrowcheck::mirborrowck 18: rustc::ty::query::querycompute::mirborrowck 19: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::mirborrowck::compute 20: rustc::depgraph::graph::DepGraph::withtaskimpl 21: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt::getquery 22: rustc::ty::<impl rustc::ty::context::TyCtxt::parbodyowners 23: rustc::util::common::time 24: rustcinterface::passes::analysis 25:

rustc::ty::query::querycompute::analysis 26: rustc::depgraph::graph::DepGraph::withtaskimpl 27: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt::getquery 28: rustc::ty::context::tls::enterglobal 29: rustcinterface::passes::BoxedGlobalCtxt::access::{{closure}} 30: rustcinterface::passes::createglobalctxt::{{closure}} 31: rustcinterface::interface::runcompilerinexistingthreadpool 32: std::thread::local::LocalKey<T::with 33: scopedtls::ScopedKey<T::set 34: syntax::withglobals note: Some details are omitted, run with for a verbose backtrace. query stack during panic: [mirborrowck] processing [analysis] running analysis passes on this crate end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.37.0-nightly ( 2019-06-06) running on x8664-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 . To learn more, run the command again with --verbose. </pre</details
Reduction:
cc
The issue is here: if doesn't have we should not take this arm, and should take the next one. Another couple of test cases:
triage: P-high, assigning to , removing I-nominated label.