Rustc panicked while unwrapping 'None'

[jeremymeadows]

Code

https://github.com/jeremymeadows/crypt/tree/29e09f5059efaf7a3202d0d401e0130d64820d3e/libcrypt

I tried to minimize the code, but it seems to have disappeared..? I have reverted back the code I committed when I got the error and it no longer panics. I don't know much about compilers, but maybe y'all can read the stack trace and find something useful, though.

It looks like there are similar reports, but this one is from a different file, so I hope I'm not duplicating reports.

Meta

rustc --version --verbose:

rustc 1.57.0 (f1edd0429 2021-11-29)
binary: rustc
commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c
commit-date: 2021-11-29
host: x86_64-unknown-linux-gnu
release: 1.57.0
LLVM version: 13.0.0

I could not get the panic to repro in nightly (1.59)

Error output

   Compiling libcrypt v1.0.0
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/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 (f1edd0429 2021-11-29) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --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 `libcrypt`

Backtrace

(I have a copy of RUST_BACKTRACE=full also, but this only asked for 1)

stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: core::panicking::panic
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/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

[BGR360]

Looks like a known incremental compilation issue. Hopefully fixed by #91919.

@rustbot label +A-incr-comp

[workingjubilee]

Yes, this is almost certainly a duplicate of this issue and was either resolved in that PR or this followup one:

• Trait selection provisional cache incorrectly handles DepNodes, leading to ICE #92987
• Properly track DepNodes in trait evaluation provisional cache #93064