Panic in <rustc_mir::monomorphize::item::InstantiationMode as core::fmt::Debug>::fmt

[kankri]

Got this error when running cargo build:

thread 'rustc' panicked at 'no entry found for key', src\libcore\option.rs:1034:5
stack backtrace:
   0: std::sys_common::alloc::realloc_fallback
   1: std::panicking::take_hook
   2: std::panicking::take_hook
   3: rustc::ty::structural_impls::<impl rustc::ty::context::Lift for rustc::ty::adjustment::AutoBorrow>::lift_to_tcx
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::option::expect_failed
   9: <rustc_mir::monomorphize::item::InstantiationMode as core::fmt::Debug>::fmt
  10: <rustc_mir::borrow_check::MirBorrowckCtxt as rustc_mir::dataflow::DataflowResultsConsumer>::visit_terminator_entry
  11: <rustc_mir::borrow_check::MirBorrowckCtxt as rustc_mir::dataflow::DataflowResultsConsumer>::visit_statement_entry
  12: rustc_mir::borrow_check::nll::facts::write_row
  13: <rustc_mir::hair::LogicalOp as core::fmt::Debug>::fmt
  14: rustc_mir::borrow_check::nll::facts::write_row
  15: <rustc_interface::util::ReplaceBodyWithLoop as syntax::mut_visit::MutVisitor>::visit_mac
  16: <rustc_interface::proc_macro_decls::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_trait_item
  17: <rustc_interface::proc_macro_decls::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_trait_item
  18: <rustc_interface::proc_macro_decls::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_trait_item
  19: <rustc_interface::proc_macro_decls::Finder as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_trait_item
  20: rustc_interface::passes::BoxedResolver::to_expansion_result
  21: rustc_driver::set_sigpipe_handler
  22: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  23: <env_logger::fmt::WriteStyle as core::default::Default>::default
  24: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  25: rustc_driver::set_sigpipe_handler
  26: rustc_interface::interface::Compiler::output_file
  27: rustc_driver::set_sigpipe_handler
  28: rustc_driver::set_sigpipe_handler
  29: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  30: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  31: rustc_driver::set_sigpipe_handler
  32: _rust_maybe_catch_panic
  33: rustc_driver::set_sigpipe_handler
  34: <std::error::<impl core::convert::From<alloc::string::String> for alloc::boxed::Box<dyn +std::error::Error+core::marker::Sync+core::marker::Send>>::from::StringError as core::fmt::Display>::fmt
  35: std::sys::windows::thread::Thread::new
  36: BaseThreadInitThunk
  37: RtlUserThreadStart
query stack during panic:
#0 [mir_borrowck] processing `find_file_in_path`
#1 [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: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.35.0 (3c235d560 2019-05-20) running on x86_64-pc-windows-msvc

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

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

The same command had been successful before, until it started failing consistently. cargo clean gave this error:

>cargo clean
error: could not remove build directory

Caused by:
  failed to remove file `target\rls\debug\deps\snafu_derive-c0f6723d479ffbaa.dll`

Caused by:
  Access is denied. (os error 5)

I noticed "rls.exe" had that DLL loaded:

   Code                       25384   8  24  478 4194303  212772  237096
      Code                     25340   8  21  332 4194303  101160  112576
        rustup                  2916   8   1  124  124912     768    2764
          conhost              19860   8   1  111 4194303    1204    1368
          rls                  20664   8   8  899  428156  112052  145368

Next steps:

• kill 20664
• cargo build: still fails the same way
• cargo clean: no errors
• cargo build: still fails the same way
• exit VS Code to avoid new RLS processes
• cargo build: still fails the same way
• cargo clean: no errors
• cargo build: still fails the same way

After commenting out the body of find_file_in_path I could compile the code again and saw both with cargo build and RLS a bunch of new errors which were not reported earlier. After fixing some of those I tried to selectively uncomment code in find_file_in_path to see what triggers the problem. I found out that the culprit was use of scopeguard::defer!{}.

I don't have a work-around for the defer! problem nor code I could share to repro the issue.

It would be nice if the compiler wouldn't crash.

[kankri]

Just a quick update: I fixed some of my errors in the source code and then reintroduced the scopequard::defer!{} I had commented out, but rustc was not panicking any more. Unfortunately I didn't save the exact source file which was causing the dump originally.

[jonas-schievink]

Another instance: #63795

Would be great to find an example to reproduce this...

[Ryan1729]

I ran into an ICE that appears to be the same as this one, since the error message also included thread 'rustc' panicked at 'no entry found for key'.

I've reduced the code down to a single crate containing a single ~20 line source file, and a single direct external dependency, which still produces an ICE. The code is available here. It is probably possible to reduce this down further, but I think it's at the point where someone else could reasonably continue to investigate.

[Aaron1011]

@Ryan1729: That example no longer ICEs on the latest nightly.

[Ryan1729]

Just to be sure, I checked my earliest commit that had the ICE on the latest nightly, and it also does not show the ICE message either. So whatever was causing my issue does seem to have been fixed.

[Enselic]

Triage: ICE fixed in nightly-2020-07-25, most likely by #74703 since it fixed another issue with an "no entry found for key" ICE, namely #74047. The fix added a regression test. Let's close this issue.