Repository navigation
trait_impls_of does not have an unique index (DepKind variant: 166) #139110
Description
I occasionally get a corrupted target directory:
thread 'rustc' panicked at /rustc/920d95eaf23d7eb6b415d09868e4f793024fa604/compiler/rustc_query_system/src/dep_graph/serialized.rs:260:21:
Error: A dep graph node (trait_impls_of) 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: 166 }(edc9942d4bc9e683-29b7d5f0f789d82)
stack backtrace:
0: 0x1108599e4 - std::backtrace::Backtrace::create::h23b6908fc40e125e
1: 0x10ea09454 - std[54631d7a81de9e90]::panicking::update_hook::<alloc[898041eeb075be66]::boxed::Box<rustc_driver_impl[cbe3ee50a9b64982]::install_ice_hook::{closure#1}>>::{closure#0}
2: 0x11087499c - std::panicking::rust_panic_with_hook::h6e33d145b73c56b6
3: 0x110874590 - std::panicking::begin_panic_handler::{{closure}}::h1b530e3befd00369
4: 0x110871f80 - std::sys::backtrace::__rust_end_short_backtrace::h08b2dd416eec9a36
5: 0x110874258 - __rustc[30d06caa1ba95d]::rust_begin_unwind
6: 0x1134cd77c - core::panicking::panic_fmt::ha09de3336dfd93b2
7: 0x10f1669ec - rustc_incremental[b6678e5139e06e3a]::persist::load::setup_dep_graph
8: 0x10e9b51b8 - rustc_interface[21db00968683b297]::passes::create_and_enter_global_ctxt::<core[edc9942d4bc9e683]::option::Option<rustc_interface[21db00968683b297]::queries::Linker>, rustc_driver_impl[cbe3ee50a9b64982]::run_compiler::{closure#0}::{closure#2}>
9: 0x10ea06098 - rustc_interface[21db00968683b297]::interface::run_compiler::<(), rustc_driver_impl[cbe3ee50a9b64982]::run_compiler::{closure#0}>::{closure#1}
10: 0x10ea2f4d4 - <rayon_core[ea3f96dfc7cd810e]::job::StackJob<rayon_core[ea3f96dfc7cd810e]::latch::LatchRef<rayon_core[ea3f96dfc7cd810e]::latch::LockLatch>, <rayon_core[ea3f96dfc7cd810e]::registry::Registry>::in_worker_cold<<rayon_core[ea3f96dfc7cd810e]::thread_pool::ThreadPool>::install<rustc_interface[21db00968683b297]::util::run_in_thread_pool_with_globals<rustc_interface[21db00968683b297]::interface::run_compiler<(), rustc_driver_impl[cbe3ee50a9b64982]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#3}::{closure#0}::{closure#1}::{closure#0}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()> as rayon_core[ea3f96dfc7cd810e]::job::Job>::execute
11: 0x1134df5c4 - <rayon_core[ea3f96dfc7cd810e]::registry::WorkerThread>::wait_until_cold
12: 0x10e0738d8 - <rayon_core[ea3f96dfc7cd810e]::registry::ThreadBuilder>::run
13: 0x10ea0d4e4 - <<crossbeam_utils[32e36cdb49266747]::thread::ScopedThreadBuilder>::spawn<<rayon_core[ea3f96dfc7cd810e]::ThreadPoolBuilder>::build_scoped<rustc_interface[21db00968683b297]::util::run_in_thread_pool_with_globals<rustc_interface[21db00968683b297]::interface::run_compiler<(), rustc_driver_impl[cbe3ee50a9b64982]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#3}::{closure#0}::{closure#0}, rustc_interface[21db00968683b297]::util::run_in_thread_pool_with_globals<rustc_interface[21db00968683b297]::interface::run_compiler<(), rustc_driver_impl[cbe3ee50a9b64982]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#3}::{closure#0}::{closure#1}, ()>::{closure#0}::{closure#0}::{closure#0}, ()>::{closure#0} as core[edc9942d4bc9e683]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
14: 0x10e9f6270 - std[54631d7a81de9e90]::sys::backtrace::__rust_begin_short_backtrace::<alloc[898041eeb075be66]::boxed::Box<dyn core[edc9942d4bc9e683]::ops::function::FnOnce<(), Output = ()> + core[edc9942d4bc9e683]::marker::Send>, ()>
15: 0x10ea0c534 - <<std[54631d7a81de9e90]::thread::Builder>::spawn_unchecked_<alloc[898041eeb075be66]::boxed::Box<dyn core[edc9942d4bc9e683]::ops::function::FnOnce<(), Output = ()> + core[edc9942d4bc9e683]::marker::Send>, ()>::{closure#1} as core[edc9942d4bc9e683]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
16: 0x110878a30 - std::sys::pal::unix::thread::Thread::new::thread_start::hc32cbdf418fc6461
17: 0x1805e5c0c - __pthread_cond_wait
rustc version: 1.87.0-nightly (920d95eaf 2025-03-28)
platform: aarch64-apple-darwin
compiler flags: --crate-type lib -C opt-level=1 -C embed-bitcode=no -C debuginfo=line-tables-only -C split-debuginfo=unpacked -C debug-assertions=on -C incremental=[REDACTED] -Z incremental-verify-ich
I have -Zincremental-verify-ich set, but it doesn't seem to change anything.
Reacted by David M., Giang Dao, Alexander Irbis, axxag, Richard Diamond, Chris, DaniPopes, Peter Wong, Finchie, Vasily Zorin and 7 more
Activity
chrisp60 commentedon Mar 31, 2025
A workaround
in a cargo config file (
.cargo/config.toml) seems to have stopped the ICE AFAICT. Obviously you lose the incremental compiles with this and YMMV.ICE
I get two flavors of ICE on
These may be the same thing but I don't know enough about the compiler to know.
(typeck)
(trait_impls_of)
tmstorey commentedon Apr 1, 2025
I've been getting a similar error on Windows x64:
compiler-errors commentedon Apr 2, 2025
cc @Zoxc #138629
Zoxc commentedon Apr 2, 2025
Could you try having
-Zincremental-verify-ichon every build after acargo clean? That is supposed to catch this sooner.Zoxc commentedon Apr 3, 2025
Could you also see if it reproduces with
nightly-2025-03-25(which includes #138629 but not #138824) and this branch which just adds this check without any other recent change to the incremental system?chrisp60 commentedon Apr 3, 2025
@Zoxc I turned on incremental compiles again for my workday, I should be able to try out various configs throughout the day as time allows.
I will start with
nightly 2025-04-02, putting together any ICE that comes along, attempting to hit the versions you mentioned.Is setting the following in my
.cargo/config.tomlthe correct way to introduce these flags?At least anecdotally, I don't remember seeing these issues much before
nightly-2025-03-25, but I am just going off memory. I can try it out though and post back.jvdwrf commentedon Apr 4, 2025
For my builds, I am getting the issue with
trait_impls_ofvery consistently when usingnightly-2025-03-28but haven't had it yet withnightly-2025-03-25.chrisp60 commentedon Apr 4, 2025
@Zoxc Here are some results of the tests you requested
I do not know how to instruct the compiler to use a specific branch as it's toolchain. But, if it would help, I can figure it out.
AFAICT I did not see any changes from enabling the
incremental-verify-ichflag, always possible that I am configuring it incorrectly though.In summary (TLDR)
nightly-03-25: no ICEICE (all produced similar results, regardless of nightly version or
incremental-verify-ichflag).Just putting these two here as all others were the same (except for memory addresses, versions, etc).
Dev setup that I use
baconto watch for changes. The exact job I use is below.Maybe the fact that bacon and the LSP are compiling at the same time influences it?
Zoxc commentedon Apr 4, 2025
It seems likely that #138824 would be the PR introducing this error. It would be helpful to have a reproduction in case that PR does not introduce the root cause here. If you have a codebase that can be shared, starting from clean slate and building different commits could be a decent way to reproduce it.
chrisp60 commentedon Apr 4, 2025
If I have time over the weekend, I can attempt to make a minimal reproduction as a shareable repo. Would be nice see this resolved.
Thank you all for the help in this matter!
Zoxc commentedon Apr 5, 2025
I see an issue in #138824 where a query can be marked green an get a node assigned, then executed later and get another node assigned. That's probably the cause of this issue.
nix: disable incremental builds for the dev shell
nix: disable incremental builds for the dev shell
nix: disable incremental builds for the dev shell
nix: disable incremental builds within the dev shell
Auto merge of rust-lang#139410 - Zoxc:fix-dep-graph-no-prev-map, r=ol…
nix: disable incremental builds for the dev shell