rustc panic (debug mode only)

[luketpeterson]

cargo test in the attached project results in a panic in rustc.
cargo test --release works without any problem

Deleting Cargo.lock and the entire target directory did not fix the issue.

Cargo project is here:
cluster_set.strip_down_to_repro_compiler_panic.zip

Unfortunately, it was a bit of a Heisenbug in that further simplification of the code make the panic disappear, but it didn't seem to follow any predictable logic. i.e. removing some functions that shouldn't have any effect made the bug go away, but then putting them back didn't make the bug return.

Meta

Panic occurs on both stable and nightly.

rustc --version --verbose:

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

and

rustc 1.59.0-nightly (efec54529 2021-12-04)
binary: rustc
commit-hash: efec545293b9263be9edfb283a7aa66350b3acbf
commit-date: 2021-12-04
host: x86_64-apple-darwin
release: 1.59.0-nightly
LLVM version: 13.0.0

Error output

Backtrace is here: (stable toolchain)
rustc_panic.txt

Also occurs on nightly:
rustc_panic.nightly.txt

[bjorn3]

Relevant excerpt:

thread 'rustc' panicked at 'forcing query with already existing `DepNode`
- query-key: Binder(cluster_set::ClusterInternal<{integer}, ()>, [])
- dep-node: own_existential_vtable_entries(a965f9c82c7a057e-34da6f267b48538f)', /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/compiler/rustc_query_system/src/dep_graph/graph.rs:247:9
stack backtrace:
[...]
  10:        0x10e3bb05f - core::panicking::panic_fmt::hb64a2db862b4aca0
  11:        0x117da5f52 - rustc_query_system::dep_graph::graph::DepGraph<K>::with_task::h14823017a5a1697e
  12:        0x117cd5f30 - rustc_data_structures::stack::ensure_sufficient_stack::haba6544b1a98446b
  13:        0x117b82975 - rustc_query_system::query::plumbing::try_execute_query::hd6604657c722c436
  14:        0x117c116fb - rustc_query_system::query::plumbing::get_query::hbda43b871f1e68ac
  15:        0x117d4f06c - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::own_existential_vtable_entries::habf6e1b1127c9ae1
  16:        0x11878aa71 - rustc_trait_selection::traits::util::count_own_vtable_entries::hf252515eecb86653
  17:        0x1187581b9 - rustc_trait_selection::traits::vtable_trait_first_method_offset::h0886bae50e69c0ef
  18:        0x11872d4be - rustc_trait_selection::traits::select::confirmation::<impl rustc_trait_selection::traits::select::SelectionContext>::confirm_candidate::hb5c10dc807d780d5
[...]

[bjorn3]

This seems to be related to incremental compilation.

Unfortunately, it was a bit of a Heisenbug in that further simplification of the code make the panic disappear, but it didn't seem to follow any predictable logic. i.e. removing some functions that shouldn't have any effect made the bug go away, but then putting them back didn't make the bug return.

Yeah, incremental compilation issues often depend on both the source and the incremental cache state. This can make it hard to create an minimal reproducer It is quite possible the panic message and location is enough to find the issue and fix it.

[dtolnay]

Closing in favor of #91807 which has a smaller repro and bisect.