ICE due to possibly corrupted cargo target folder

[jdonszelmann]

Code

This internal compiler error has not been caused by any specific code. I got it when I ran cargo test on a library. I went back through my git history to find a known-good commit on which cargo test passed. However, I got the backtrace as shown below even on this known-good version of the codebase.

I suspected my target folder somehow got corrupted. Therefore I made a backup of it, removed it and rebuilt the entire project. This removed the ICE.

This leads me to believe that rust/cargo somehow got its own target folder in a weird state where compilation was no longer possible.

I attached my target folder of when the error occurred here if its of any use. I understand that this entire issue report doesn't provide much to go on. I still decided to report it since in general I don't think ICEs are ever desired.

EDIT: I moved by backup target folder back to see if I could reproduce the bug and I couldn't. This means we've got even less to go on :(.

Meta

rustc --version --verbose:

rustc 1.58.1 (db9d1b20b 2022-01-20)
binary: rustc
commit-hash: db9d1b20bba1968c1ec1fc49616d4742c1725b4b
commit-date: 2022-01-20
host: x86_64-unknown-linux-gnu
release: 1.58.1
LLVM version: 13.0.0

Error output

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/compiler/rustc_hir/src/definitions.rs:452:14
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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.58.1 (db9d1b20b 2022-01-20) running on x86_64-unknown-linux-gnu

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

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

query stack during panic:
#0 [analysis] running analysis passes on this crate
end of query stack

Backtrace

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/compiler/rustc_hir/src/definitions.rs:452:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:107:14
   2: core::panicking::panic
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:48:5
   3: <rustc_middle::ty::context::TyCtxt>::def_path_hash_to_def_id
   4: <rustc_query_system::dep_graph::dep_node::DepNode<rustc_middle::dep_graph::dep_node::DepKind> as rustc_middle::dep_graph::dep_node::DepNodeExt>::extract_def_id
   5: rustc_query_impl::query_callbacks::hir_owner::force_from_dep_node
   6: <rustc_middle::ty::context::TyCtxt as rustc_query_system::dep_graph::DepContext>::try_force_from_dep_node
   7: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::try_mark_previous_green::<rustc_query_impl::plumbing::QueryCtxt>
   8: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::try_mark_previous_green::<rustc_query_impl::plumbing::QueryCtxt>
   9: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::try_mark_previous_green::<rustc_query_impl::plumbing::QueryCtxt>
  10: rustc_query_system::query::plumbing::ensure_must_run::<rustc_query_impl::plumbing::QueryCtxt, rustc_span::def_id::DefId, rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrs>
  11: rustc_query_system::query::plumbing::get_query::<rustc_query_impl::queries::coherent_trait, rustc_query_impl::plumbing::QueryCtxt>
  12: rustc_typeck::coherence::check_coherence
  13: <rustc_session::session::Session>::track_errors::<rustc_typeck::check_crate::{closure#3}, ()>
  14: rustc_typeck::check_crate
  15: rustc_interface::passes::analysis
  16: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::with_task::<rustc_middle::ty::context::TyCtxt, (), core::result::Result<(), rustc_errors::ErrorReported>>
  17: rustc_data_structures::stack::ensure_sufficient_stack::<(core::result::Result<(), rustc_errors::ErrorReported>, rustc_query_system::dep_graph::graph::DepNodeIndex), rustc_query_system::query::plumbing::execute_job<rustc_query_impl::plumbing::QueryCtxt, (), core::result::Result<(), rustc_errors::ErrorReported>>::{closure#3}>
  18: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::plumbing::QueryCtxt, rustc_query_system::query::caches::DefaultCache<(), core::result::Result<(), rustc_errors::ErrorReported>>>
  19: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  20: <rustc_interface::passes::QueryContext>::enter::<rustc_driver::run_compiler::{closure#1}::{closure#2}::{closure#3}, core::result::Result<(), rustc_errors::ErrorReported>>
  21: <rustc_interface::interface::Compiler>::enter::<rustc_driver::run_compiler::{closure#1}::{closure#2}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_errors::ErrorReported>>
  22: rustc_span::with_source_map::<core::result::Result<(), rustc_errors::ErrorReported>, rustc_interface::interface::create_compiler_and_run<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>::{closure#1}>
  23: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::util::setup_callbacks_and_run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorReported>>::{closure#0}::{closure#0}, core::result::Result<(), rustc_errors::ErrorReported>>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[jdonszelmann]

Apparently github doesn't like attaching large zips to an issue. If anyone is interested in the target directory, please tell me in what way I can provide it most easily. It's 700Mb large.

[Aaron1011]

Can you update to the latest nightly? If this happens again, you should get a crash with a more detailed error message.

[jdonszelmann]

I will give it a try. I hope I can reproduce it.

[jdonszelmann]

🎉 I have been able to reproduce this error. While working on the same project it just sort of happened again. This time I could try it with nightly.

However, on nightly I cannot reproduce the bug as compiling with nightly rebuilds the target directory (for nightly) solving the issue.

I will keep working on the project in nightly for a while to try to reproduce it properly.

I accidentally rebuilt my cargo target directory (I changed a compiler flag) so I don't have a backup of the version that caused the ICE. However, this might not be very useful anyway since we established earlier that tarring/untarring it resolved the bug.

@Aaron1011

[workingjubilee]

Thank you for confirming this has been fixed!