rust-lang/rust · critical

counting sort fills every slot of a kind's range

Error message

counting sort fills every slot of a kind's range

What it means

Fires while building the reverse index of the serialized incremental dep-graph (serialized.rs:189). For each `DepKind`, the dep-graph stores a contiguous range of node slots produced by a counting sort; iterating that range, every slot must hold a node index. `idx.expect("counting sort fills every slot of a kind's range")` panics when a slot is `None`, meaning the counting sort left a hole and the serialized dep-graph is internally inconsistent.

Solutions

1. Run `cargo clean` (or delete `target/<profile>/incremental/`) to discard the corrupt dep-graph and rebuild non-incrementally once.
2. Disable incremental compilation for the affected profile (`CARGO_INCREMENTAL=0`) if the corruption recurs.
3. Ensure the same rustc version owns the whole `target/` dir; do not reuse it across toolchain changes.
4. Reproduces on a clean incremental build -> file an ICE; run with `-Z incremental-verify-ich` to help narrow the fingerprint issue.

# Discard the corrupt dep-graph and rebuild once without incremental
rm -rf target/debug/incremental target/release/incremental
# or globally:
export CARGO_INCREMENTAL=0
cargo build

cargo build || { rm -rf target/*/incremental && cargo build; }

When it happens

Trigger: Loading an incremental compilation cache (`target/<profile>/incremental/`) whose dep-graph was corrupted or written by an incompatible rustc; a previous build was interrupted while writing the dep-graph; fingerprint collisions producing duplicate node indices (the adjacent panic at line 196 catches the non-SideEffect duplicate case).

Common situations: Reusing an incremental cache across rustc versions or across incompatible commits; a killed/crashed previous build leaving a half-written dep-graph; disk corruption in `target/`; clock/FS races on shared build dirs.

Related errors

• no encoded ident for item
• Accessing live loans requires `-Zpolonius=next`
• Already encoded SourceMap!
• alt layout should always work
• alt layout should have a niche like the regular one

AI-assisted analysis of rust-lang/rust@7088e4b63a (2026-08-10). Data as JSON: /api/errors/3378c1560700ea47. Report an issue: GitHub.

Appendix: source

Thrown at compiler/rustc_middle/src/dep_graph/serialized.rs:189

impl LazyKindIndex {
    /// Returns this kind's `key_fingerprint -> node index` map.
    fn fingerprint_map(
        &self,
        kind: DepKind,
        nodes: &IndexSlice<SerializedDepNodeIndex, DepNode>,
        nodes_by_kind: &[Option<SerializedDepNodeIndex>],
        profiler: &Option<SelfProfilerRef>,
    ) -> &UnhashMap<PackedFingerprint, SerializedDepNodeIndex> {
        self.map.get_or_init(|| {
            let _prof_timer = profiler
                .as_ref()
                .map(|p| p.generic_activity("incr_comp_load_dep_graph_reverse_index"));
            let range = (self.start as usize)..(self.start as usize + self.len as usize);
            let mut map =
                UnhashMap::with_capacity_and_hasher(self.len as usize, Default::default());
            for &idx in &nodes_by_kind[range] {
                let idx = idx.expect("counting sort fills every slot of a kind's range");
                let node = nodes[idx];
                debug_assert_eq!(node.kind, kind);
                if map.insert(node.key_fingerprint, idx).is_some()
                    // Side effect nodes can legitimately share a fingerprint.
                    && node.kind != DepKind::SideEffect
                {
                    panic!(
                        "Error: A dep graph node ({kind:?}) 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.\n
                         DepNode: {node:?}"
                    )
                }
            }
            map
        })
    }

View on GitHub (pinned to 7088e4b63a)