Closed as not planned
Closed as not planned
Description
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 waycargo clean
: no errorscargo build
: still fails the same way- exit VS Code to avoid new RLS processes
cargo build
: still fails the same waycargo clean
: no errorscargo 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.
Metadata
Metadata
Assignees
Labels
Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Incremental compilationCategory: This is a bug.Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Relevant to the compiler team, which will review and decide on the PR/issue.