ICE: "Forcing query with already existing 'DepNode'

[ffrogman]

I think the error has to do with the fact that I have the same static str "DUMMY". If I change the strings to be nonidentical the panic no longer occurs. This was slimmed down from a much bigger example. I know the code may still not compile even once the panic is fixed, but it still should not panic.

Code

use std::fmt;

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

const Dummy1: StaticString = StaticString {
    string: "DUMMY",
    };
const Dummy2: StaticString = StaticString {
    string: "DUMMY",
    };

impl fmt::Display for StaticString {
    fn fmt(&self, formatter: &mut fmt::Formatter) -> fmt::Result {
        let mut name = match *self {
            Dummy1 => "1",
            Dummy2 => "2",
        };

        formatter.write_str(name)
    }
}

fn main() {
}

Meta

rustc --version --verbose:

rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: armv7-unknown-linux-gnueabihf
release: 1.48.0
LLVM version: 11.0

Also occurs on

rustc 1.50.0-nightly (1700ca07c 2020-12-08)
binary: rustc
commit-hash: 1700ca07c6dd7becff85678409a5df6ad4cf4f47
commit-date: 2020-12-08
host: armv7-unknown-linux-gnueabihf
release: 1.50.0-nightly

Error output

`rustc --crate-name panic --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=c33a0de415a5d6e1 -C extra-filename=-c33a0de415a5d6e1 --out-dir /home/panic/target/debug/deps -C incremental=/home/panic/target/debug/incremental -L dependency=/home/panic/target/debug/deps`
thread 'rustc' panicked at 'forcing query with already existing `DepNode`
- query-key: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: UserFacing }, value: Const { ty: StaticString, val: Value(ByRef { alloc: Allocation { bytes: [0, 0, 0, 0, 5, 0, 0, 0], relocations: Relocations(SortedMap { data: [(Size { raw: 0 }, ((), alloc6))] }), init_mask: InitMask { blocks: [255], len: Size { raw: 8 } }, size: Size { raw: 8 }, align: Align { pow2: 2 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }) } }
- dep-node: destructure_const(33e621e72d1b34c1-63a66fbf62362c7e)', /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/compiler/rustc_query_system/src/query/plumbing.rs:577:5
stack backtrace:

[[Submitor note: SEE OTHER SECTION BELOW]]

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.48.0 (7eac88abb 2020-11-16) running on armv7-unknown-linux-gnueabihf

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

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

query stack during panic:
#0 [check_match] match-checking `<StaticString as std::fmt::Display>::fmt`
#1 [analysis] running analysis passes on this crate
end of query stack
error: could not compile `panic`

Caused by:
  process didn't exit successfully: `rustc --crate-name panic --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=c33a0de415a5d6e1 -C extra-filename=-c33a0de415a5d6e1 --out-dir /home/panic/target/debug/deps -C incremental=/home/panic/target/debug/incremental -L dependency=/home/panic/target/debug/deps` (exit code: 101)

Backtrace

   0: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
   1: std::panicking::begin_panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:437
   2: rustc_query_system::query::plumbing::get_query_impl
   3: rustc_mir_build::thir::pattern::const_to_pat::ConstToPat::recur
   4: rustc_infer::infer::InferCtxtBuilder::enter
   5: rustc_mir_build::thir::pattern::PatCtxt::lower_path
   6: rustc_mir_build::thir::pattern::PatCtxt::lower_pattern
   7: rustc_mir_build::thir::pattern::check_match::MatchVisitor::lower_pattern
   8: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   9: <rustc_mir_build::thir::pattern::check_match::MatchVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  10: <rustc_mir_build::thir::pattern::check_match::MatchVisitor as rustc_hir::intravisit::Visitor>::visit_local
  11: rustc_hir::intravisit::walk_expr
  12: <rustc_mir_build::thir::pattern::check_match::MatchVisitor as rustc_hir::intravisit::Visitor>::visit_expr
  13: rustc_mir_build::thir::pattern::check_match::check_match
  14: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::check_match>::compute
  15: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  16: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  17: rustc_data_structures::stack::ensure_sufficient_stack
  18: rustc_query_system::query::plumbing::get_query_impl
  19: rustc_query_system::query::plumbing::ensure_query_impl
  20: rustc_session::utils::<impl rustc_session::session::Session>::time
  21: rustc_session::utils::<impl rustc_session::session::Session>::time
  22: rustc_interface::passes::analysis
  23: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::analysis>::compute
  24: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  25: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  26: rustc_data_structures::stack::ensure_sufficient_stack
  27: rustc_query_system::query::plumbing::get_query_impl
  28: rustc_interface::passes::QueryContext::enter
  29: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  30: rustc_span::with_source_map
  31: rustc_interface::interface::create_compiler_and_run
  32: scoped_tls::ScopedKey<T>::set

[SNCPlay42]

This was a 1.41->1.42 regression per Godbolt, needs incremental compilation on to repro.

Adding a match arm like _ => "Foo" (as I have on godbolt) makes this compile on 1.41 but it still ICEs on later versions.

@rustbot label A-incr-comp regression-from-stable-to-stable

[apiraino]

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[ngc0202]

It appears to be a regression at nightly-2020-01-13. My (unverified) guess is that it arose in 59c1db0.

[ffrogman]

For what it's worth is simpler and produces a similar panic:

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

const DUMMY1: StaticString = StaticString {
    string: "DUMMY",
    };
const DUMMY2: StaticString = StaticString {
    string: "DUMMY",
    };

fn main() {
    let bar = DUMMY1;
    let name = match bar {
            DUMMY1 => "1",
            DUMMY2 => "2",
            _ => "Foo",
    };
}

[rossmacarthur]

Also encountered this error (rust-lang/rust-clippy#7373), while using Clippy (on nightly only), reduced it to the following:

cargo +nightly clippy

// lib.rs
use std::collections::HashMap;

type Map<'a> = HashMap<&'a str, &'a str>;

fn a(_: &()) -> Map {
    todo!()
}

fn b<'a>(_: &'a Map) {
    todo!()
}

Backtrace

thread 'rustc' panicked at 'forcing query with already existing `DepNode`
- query-key: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: All }, value: &str }
- dep-node: layout_raw(ad738982f22c678a-9e7e0f2c32792904)', /rustc/a435b49e86d16e98dcc6595dd471f95e823f41aa/compiler/rustc_query_system/src/query/plumbing.rs:645:5
stack backtrace:
   0: _rust_begin_unwind
   1: std::panicking::begin_panic_fmt
   2: rustc_query_system::query::plumbing::get_query_impl
   3: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::layout_raw
   4: <rustc_middle::ty::layout::LayoutCx<rustc_middle::ty::context::TyCtxt> as rustc_target::abi::LayoutOf>::layout_of
   5: <rustc_lint::context::LateContext as rustc_target::abi::LayoutOf>::layout_of
   6: <clippy_lints::zero_sized_map_values::ZeroSizedMapValues as rustc_lint::passes::LateLintPass>::check_ty
   7: <rustc_lint::late::LateLintPassObjects as rustc_lint::passes::LateLintPass>::check_ty
   8: rustc_hir::intravisit::walk_ty
   9: rustc_hir::intravisit::walk_fn
  10: <rustc_lint::late::LateContextAndPass<T> as rustc_hir::intravisit::Visitor>::visit_fn
  11: rustc_hir::intravisit::walk_item
  12: rustc_hir::intravisit::Visitor::visit_nested_item
  13: rustc_hir::intravisit::walk_crate
  14: rustc_lint::late::late_lint_pass_crate
  15: rustc_lint::late::late_lint_crate
  16: rustc_data_structures::sync::join
  17: rustc_interface::passes::analysis::{{closure}}::{{closure}}
  18: rustc_session::utils::<impl rustc_session::session::Session>::time
  19: rustc_interface::passes::analysis
  20: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  21: rustc_data_structures::stack::ensure_sufficient_stack
  22: rustc_query_system::query::plumbing::force_query_with_job
  23: rustc_query_system::query::plumbing::get_query_impl
  24: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
  25: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  26: rustc_span::with_source_map
  27: rustc_interface::interface::create_compiler_and_run
  28: scoped_tls::ScopedKey<T>::set
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-clippy/issues/new

note: Clippy version: clippy 0.1.54 (a435b49e 2021-06-28)

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

[cjgillot]

Closing as duplicate of #83085 which is tracked by glacier.
Per #83085 (comment), fully resolving this issue probably needs a significant implementation work.