Skip to content

A dep graph node (mir_drops_elaborated_and_const_checked) does not have an unique index #141540

Description

@dfaust

The error has been occurring sporadically for like a week or two with recent nightly versions. Unfortunately I don't have more details, please let me know if I can help somehow.

Error output

thread 'rustc' panicked at /rustc/3e674b06b5c74adea662bd0b0b06450757994b16/compiler/rustc_query_system/src/dep_graph/serialized.rs:284:21:
Error: A dep graph node (mir_drops_elaborated_and_const_checked) does not have an unique index. Running a clean build on a nightly compiler with `-Z incremental-verify-ich` can help narrow down the issue for reporting. A clean build may also work around the issue.

                     DepNode: DepKind { variant: 55 }(66f52541bc7a3a54-9342199b53a1abb9)
stack backtrace:
   0:     0x7f110d0d9ee5 - std::backtrace::Backtrace::create::hfa425f8c6118c291
   1:     0x7f110b558655 - std::backtrace::Backtrace::force_capture::hc89ba712c3edf9d4
   2:     0x7f110a59b841 - std[dddea0bc0c38a8db]::panicking::update_hook::<alloc[ad07e7cbb7f1de4e]::boxed::Box<rustc_driver_impl[40f87d5870cfacca]::install_ice_hook::{closure#1}>>::{closure#0}
   3:     0x7f110b572583 - std::panicking::rust_panic_with_hook::hedd3f60f85824998
   4:     0x7f110b57227a - std::panicking::begin_panic_handler::{{closure}}::hf9de1d740cfa85c9
   5:     0x7f110b56e779 - std::sys::backtrace::__rust_end_short_backtrace::h60f7d5e7789cd81b
   6:     0x7f110b571f3d - __rustc[6241699db995e819]::rust_begin_unwind
   7:     0x7f1107e89ee0 - core::panicking::panic_fmt::h4e2563c759f41a6b
   8:     0x7f110cd6347f - rustc_incremental[e2943fc0bf579b13]::persist::load::setup_dep_graph
   9:     0x7f110cd1b204 - rustc_interface[3a0a2c43e50c5194]::interface::run_compiler::<(), rustc_driver_impl[40f87d5870cfacca]::run_compiler::{closure#0}>::{closure#1}
  10:     0x7f110a5af124 - <rayon_core[450d1f61637cc29a]::job::StackJob<rayon_core[450d1f61637cc29a]::latch::LatchRef<rayon_core[450d1f61637cc29a]::latch::LockLatch>, <rayon_core[450d1f61637cc29a]::registry::Registry>::in_worker_cold<<rayon_core[450d1f61637cc29a]::thread_pool::ThreadPool>::install<rustc_interface[3a0a2c43e50c5194]::util::run_in_thread_pool_with_globals<rustc_interface[3a0a2c43e50c5194]::interface::run_compiler<(), rustc_driver_impl[40f87d5870cfacca]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#5}::{closure#0}::{closure#1}::{closure#0}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()> as rayon_core[450d1f61637cc29a]::job::Job>::execute
  11:     0x7f110a04404e - <rayon_core[450d1f61637cc29a]::registry::WorkerThread>::wait_until_cold
  12:     0x7f110a0419d1 - <rayon_core[450d1f61637cc29a]::registry::ThreadBuilder>::run
  13:     0x7f110a59175d - std[dddea0bc0c38a8db]::sys::backtrace::__rust_begin_short_backtrace::<<rayon_core[450d1f61637cc29a]::ThreadPoolBuilder>::build_scoped<rustc_interface[3a0a2c43e50c5194]::util::run_in_thread_pool_with_globals<rustc_interface[3a0a2c43e50c5194]::interface::run_compiler<(), rustc_driver_impl[40f87d5870cfacca]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#5}::{closure#0}::{closure#0}, rustc_interface[3a0a2c43e50c5194]::util::run_in_thread_pool_with_globals<rustc_interface[3a0a2c43e50c5194]::interface::run_compiler<(), rustc_driver_impl[40f87d5870cfacca]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#5}::{closure#0}::{closure#1}, ()>::{closure#0}::{closure#0}::{closure#0}, ()>
  14:     0x7f110a59ffb2 - <<std[dddea0bc0c38a8db]::thread::Builder>::spawn_unchecked_<<rayon_core[450d1f61637cc29a]::ThreadPoolBuilder>::build_scoped<rustc_interface[3a0a2c43e50c5194]::util::run_in_thread_pool_with_globals<rustc_interface[3a0a2c43e50c5194]::interface::run_compiler<(), rustc_driver_impl[40f87d5870cfacca]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#5}::{closure#0}::{closure#0}, rustc_interface[3a0a2c43e50c5194]::util::run_in_thread_pool_with_globals<rustc_interface[3a0a2c43e50c5194]::interface::run_compiler<(), rustc_driver_impl[40f87d5870cfacca]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#5}::{closure#0}::{closure#1}, ()>::{closure#0}::{closure#0}::{closure#0}, ()>::{closure#1} as core[a1eebbb7364c739]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  15:     0x7f110ccc66fd - std::sys::pal::unix::thread::Thread::new::thread_start::h337190b46df16ff4
  16:     0x7f1106899546 - start_thread
  17:     0x7f110691d94c - __GI___clone3
  18:                0x0 - <unknown>


rustc version: 1.89.0-nightly (3e674b06b 2025-05-23)
platform: x86_64-unknown-linux-gnu

Work-around

You can disable incremental compilation to avoid this issue.
There are multiple ways to do it, for example:

Add this to $WORKSPACE/.cargo/config.toml:

[build]
incremental = false

or set the CARGO_INCREMENTAL environment variable:

export CARGO_INCREMENTAL=0

Activity

  1. added
    I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    C-bugCategory: This is a bug.
    on May 25, 2025
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on May 25, 2025
  3. added
    A-query-systemArea: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html)
    A-incr-compArea: Incremental compilation
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Jun 1, 2025
  4. nastynaz commented on Jun 7, 2025

    @nastynaz

    The same for me. It's really frustrating. A cargo clean sometimes fixes it but it randomly comes back. @dfaust did you ever figure it out?

  5. dfaust commented on Jun 7, 2025

    @dfaust
    Author

    @nastynaz I disabled incremental compilation. No issues since.

  6. nastynaz commented on Jun 10, 2025

    @nastynaz

    @dfaust

    This was the only thing that fixed it for me. Thanks for sharing. It's slightly annoying having longer compile times but better than the previous flakiness. Out of curiosity, are you using #![feature(generic_const_exprs)] anywhere in your code? The compiler had an issue with this in the past that was supposedly fixed and I wonder whether it's the same bug cropping up in a different form.

  7. dfaust commented on Jun 10, 2025

    @dfaust
    Author

    @nastynaz

    are you using #![feature(generic_const_exprs)] anywhere in your code?

    No, I'm not.

  8. added
    S-needs-reproStatus: This issue has no reproduction and needs a reproduction to make progress.
    on Jun 11, 2025
  9. mirsella commented on Jun 12, 2025

    @mirsella

    hey, still hapenning as of 2025, June 12.
    personally it happens when multiples cargo commands are running at the same time (waiting for file lock on package cache). there might a be problem synchronization problem on the cache. of course after cargo clean everything is back to working

  10. mischnic commented on Jun 23, 2025

    @mischnic

    I'm seeing this multiple times per hour while working on this Turbopack: https://github.com/vercel/next.js/tree/canary/turbopack/crates which does use a number of nightly features, but not generic_const_exprs.
    I have no simple way to reproduce this, but it does always eventually happen after changing code and compiling often enough.

  11. 27 remaining items

  12. added a commit that references this issue on Dec 13, 2025
  13. added a commit that references this issue on Dec 13, 2025
  14. zetanumbers commented on Dec 14, 2025

    @zetanumbers
    Contributor

    Latest nightly (2025-12-13) might have made some progress on this issue due to #149916. So consider updating your nightly toolchain.

    UPDATE: Sadly it doesn't help to temporary fix this issue with a rebuild. Although the issue have progressed to #150018

  15. petrochenkov commented on Dec 19, 2025

    @petrochenkov
    Contributor

    Issue debugged, a solution is proposed in #150156.

  16. mischnic commented on Jan 15, 2026

    @mischnic

    So this particular bug might be fixed now, I haven't seen it for days. (on 2026-01-03)

    It feels like the compiler crashes just as often though, but instead with different error messages: #150018 (comment)

  17. added 2 commits that reference this issue on Feb 10, 2026
    0c09117
    9e79395
  18. added 4 commits that reference this issue on Feb 13, 2026
    298b33d
    210c39b
    7194876
    ca5e141
  19. added a commit that references this issue on Aug 7, 2026
    a75abf5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-incr-compArea: Incremental compilationA-parallel-compilerArea: parallel compilerA-query-systemArea: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html)C-bugCategory: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️S-needs-reproStatus: This issue has no reproduction and needs a reproduction to make progress.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions