rustc panicked, called Option::unwrap on None in DefPathTable::local_def_path_hash_to_def_id

[pr2502]

This has happened to me twice today on the at-the-time current nightly, first time I ran cargo clean and the error went away and this time I ran a different nightly while trying to find out more and that also made the error go away.

To me it seems to be related to some on-disk cache so it might be relevant that it happened while I was running rust-analyzer and both rustc and rustdoc on every file change and they'd race each time who gets to run first.

Code

This doesn't seem to be caused by the code itself, if I undo my last change before the crash appears it persists and it goes away with cargo clean without any change to code.

Meta

rustc --version --verbose:

rustc 1.57.0-nightly (73422130e 2021-09-24)
binary: rustc
commit-hash: 73422130ee96c09e7214c876a3600ac1f32aa8c8
commit-date: 2021-09-24
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0

Error output

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/73422130ee96c09e7214c876a3600ac1f32aa8c8/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.57.0-nightly (73422130e 2021-09-24) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C linker=clang -C incremental -C link-arg=-fuse-ld=/usr/local/bin/mold --crate-type lib

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
error: could not compile `lipo`

Backtrace

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/73422130ee96c09e7214c876a3600ac1f32aa8c8/compiler/rustc_hir/src/definitions.rs:452:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/73422130ee96c09e7214c876a3600ac1f32aa8c8/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/73422130ee96c09e7214c876a3600ac1f32aa8c8/library/core/src/panicking.rs:100:14
   2: core::panicking::panic
             at /rustc/73422130ee96c09e7214c876a3600ac1f32aa8c8/library/core/src/panicking.rs:50:5
   3: <rustc_query_impl::on_disk_cache::OnDiskCache as rustc_middle::ty::context::OnDiskCache>::def_path_hash_to_def_id
   4: rustc_middle::dep_graph::dep_node::<impl rustc_query_system::dep_graph::dep_node::DepNodeParams<rustc_middle::ty::context::TyCtxt> for rustc_span::def_id::LocalDefId>::recover
   5: rustc_query_impl::query_callbacks::hir_owner::force_from_dep_node
   6: rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green
   7: rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green
   8: rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green
   9: rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green
  10: rustc_query_system::query::plumbing::ensure_must_run
  11: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::coherent_trait
  12: rustc_session::session::Session::track_errors
  13: rustc_typeck::check_crate
  14: rustc_interface::passes::analysis
  15: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  16: rustc_data_structures::stack::ensure_sufficient_stack
  17: rustc_query_system::query::plumbing::try_execute_query
  18: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  19: rustc_interface::passes::QueryContext::enter
  20: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  21: rustc_span::with_source_map
  22: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace

[Aaron1011]

cc @michaelwoerister

[th1000s]

I could reliably reproduce this by switching from stable to nightly and then sequentially checking a few commits, see #89539.

[BGR360]

Possible dupe of #91696. Hopefully fixed by #91919.

@rustbot label +A-incr-comp

[workingjubilee]

Closing assuming the previous "it's a duplicate" is correct, because it seems so to my eyes. Should be fixed by either that or #93064