ICE on match of const variables: destructure_const

[sffc]

I am getting an ICE on the following code.

The ICE is always reproducible in a clean build, but in an incremental build, I can bypass the ICE by removing the foo function, compiling, and then adding the foo function back again.

This is possibly related to #89690 or #83085 given the similar error message, but I am filing a new issue with my own reduced case because the stack is different.

Code

Gist: https://gist.github.com/sffc/f09a3a468a82210a713dc9d8b408b46d

#[derive(PartialEq, Eq)]
pub struct Key {
    path: &'static str,
}

pub const CONST_A: Key = Key {
    path: "time_zone/formats@1",
};

pub const CONST_B: Key = Key {
    path: "time_zone/formats@1",
};

fn foo(key: Key) -> Result<(), &'static str> {
    match key {
        CONST_B => Ok(()),
        _ => Err(""),
    }
}

fn bar(key: Key) -> Result<(), &'static str> {
    match key {
        CONST_A => Ok(()),
        _ => Err(""),
    }
}

Meta

rustc --version --verbose:

$ 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 'forcing query with already existing `DepNode`
- query-key: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: UserFacing }, value: Const { ty: Key, val: Value(ByRef { alloc: Allocation { bytes: [0, 0, 0, 0, 0, 0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0], relocations: Relocations(SortedMap { data: [(Size { raw: 0 }, alloc7)] }), init_mask: InitMask { blocks: [65535], len: Size { raw: 16 } }, align: Align { pow2: 3 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }) } }
- dep-node: destructure_const(94ed374db4be2c96-604af2b3d231c21a)', /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/compiler/rustc_query_system/src/dep_graph/graph.rs:236:9
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 --crate-type lib

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

query stack during panic:
#0 [destructure_const] destructure constant
#1 [check_match] match-checking `bar`
end of query stack
error: could not compile `ice_destructure_const`

Backtrace

thread 'rustc' panicked at 'forcing query with already existing `DepNode`
- query-key: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: UserFacing }, value: Const { ty: Key, val: Value(ByRef { alloc: Allocation { bytes: [0, 0, 0, 0, 0, 0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0], relocations: Relocations(SortedMap { data: [(Size { raw: 0 }, alloc7)] }), init_mask: InitMask { blocks: [65535], len: Size { raw: 16 } }, align: Align { pow2: 3 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }) } }
- dep-node: destructure_const(94ed374db4be2c96-604af2b3d231c21a)', /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/compiler/rustc_query_system/src/dep_graph/graph.rs:236:9
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: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::with_task::<rustc_middle::ty::context::TyCtxt, rustc_middle::ty::ParamEnvAnd<&rustc_middle::ty::consts::Const>, rustc_middle::mir::query::DestructuredConst>
   3: rustc_data_structures::stack::ensure_sufficient_stack::<(rustc_middle::mir::query::DestructuredConst, rustc_query_system::dep_graph::graph::DepNodeIndex), rustc_query_system::query::plumbing::execute_job<rustc_query_impl::plumbing::QueryCtxt, rustc_middle::ty::ParamEnvAnd<&rustc_middle::ty::consts::Const>, rustc_middle::mir::query::DestructuredConst>::{closure#3}>
   4: rustc_query_system::query::plumbing::get_query::<rustc_query_impl::queries::destructure_const, rustc_query_impl::plumbing::QueryCtxt>
   5: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::destructure_const
   6: <rustc_mir_build::thir::pattern::const_to_pat::ConstToPat>::recur
   7: <rustc_infer::infer::InferCtxtBuilder>::enter::<rustc_middle::thir::Pat, <rustc_mir_build::thir::pattern::PatCtxt>::const_to_pat::{closure#0}>
   8: <rustc_mir_build::thir::pattern::PatCtxt>::lower_path
   9: <rustc_mir_build::thir::pattern::PatCtxt>::lower_pattern
  10: <rustc_mir_build::thir::pattern::check_match::MatchVisitor>::lower_pattern
  11: <alloc::vec::Vec<rustc_mir_build::thir::pattern::usefulness::MatchArm> as alloc::vec::spec_from_iter::SpecFromIter<rustc_mir_build::thir::pattern::usefulness::MatchArm, core::iter::adapters::map::Map<core::slice::iter::Iter<rustc_hir::hir::Arm>, <rustc_mir_build::thir::pattern::check_match::MatchVisitor>::check_match::{closure#0}>>>::from_iter
  12: <rustc_mir_build::thir::pattern::check_match::MatchVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  13: <rustc_mir_build::thir::pattern::check_match::MatchVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  14: rustc_mir_build::thir::pattern::check_match::check_match
  15: <rustc_query_system::dep_graph::graph::DepGraph<rustc_middle::dep_graph::dep_node::DepKind>>::with_task::<rustc_middle::ty::context::TyCtxt, rustc_span::def_id::DefId, ()>
  16: rustc_data_structures::stack::ensure_sufficient_stack::<((), rustc_query_system::dep_graph::graph::DepNodeIndex), rustc_query_system::query::plumbing::execute_job<rustc_query_impl::plumbing::QueryCtxt, rustc_span::def_id::DefId, ()>::{closure#3}>
  17: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::plumbing::QueryCtxt, rustc_query_system::query::caches::DefaultCache<rustc_span::def_id::DefId, ()>>
  18: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::check_match
  19: <rustc_middle::hir::map::Map>::par_body_owners::<rustc_interface::passes::analysis::{closure#1}::{closure#0}::{closure#0}::{closure#0}>
  20: <rustc_session::session::Session>::time::<(), rustc_interface::passes::analysis::{closure#1}>
  21: rustc_interface::passes::analysis
  22: <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>>
  23: 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}>
  24: 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>>>
  25: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  26: <rustc_interface::passes::QueryContext>::enter::<rustc_driver::run_compiler::{closure#1}::{closure#2}::{closure#3}, core::result::Result<(), rustc_errors::ErrorReported>>
  27: <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>>
  28: 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}>
  29: <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.

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 --crate-type lib

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

query stack during panic:
#0 [destructure_const] destructure constant
#1 [check_match] match-checking `bar`
#2 [analysis] running analysis passes on this crate
end of query stack
error: could not compile `ice_destructure_const`

[compiler-errors]

I tracked down the HashStable implementation bug to SortedMap Relocations AllocId. The Eq impl doesn't match the HashStable impl.

Let me see if I can put a PR up.

@rustbot claim

[compiler-errors]

So AllocId acts somewhat like a plain NonZero number (its Eq impl), and somewhat like a reference (its HashStable impl, which it resolves to the underlying allocation to be stable according to that impl).

The issue here is we have two allocation IDs pointing to the same underlying allocation, so their HashStable collides but their Eq implementations say they're unequal.

Not sure what behavior we want. It seems like we need to differentiate AllocIds in structs that should behave like the existing HashStable behavior (unwrapping and comparing their inner allocations), and AllocIds that act just like newtype wrappers around numbers.

cc: @oli-obk (saw you added this HashStable impl in #46882).

[compiler-errors]

also cc: @Aaron1011, this might have to do something with HashStableEq.

(would using that trait have prevented this? just saw the PR a few hours ago, didn't have time to look it over yet!)

[apiraino]

Closing as duplicate in favor of #83085 (which has a patch for fixing the issue in progress)