rust-lang/rust · critical

Incremental cache file size overflowed u64.

Error message

Incremental cache file size overflowed u64.

What it means

`AbsoluteBytePos::new` (on_disk_cache.rs:122) converts a `usize` byte offset into the on-disk incremental cache into a `u64` via `try_into().expect(...)`. The conversion only fails for offsets beyond 2^64 bytes (≈16 EiB), which is physically unreachable for any real file. The panic exists as a defensive guard against corrupted length math upstream, not as a realistic capacity limit.

Source

Thrown at compiler/rustc_middle/src/query/on_disk_cache.rs:122

    // without measurable overhead. This permits larger const allocations without ICEing.
    interpret_alloc_index: Vec<u64>,
    // See `OnDiskCache.syntax_contexts`
    syntax_contexts: FxHashMap<u32, AbsoluteBytePos>,
    // See `OnDiskCache.expn_data`
    expn_data: UnhashMap<ExpnHash, AbsoluteBytePos>,
    foreign_expn_data: UnhashMap<ExpnHash, u32>,
}

#[derive(Copy, Clone, PartialEq, Eq, Hash, Debug, Encodable, Decodable)]
struct SourceFileIndex(u32);

#[derive(Copy, Clone, Debug, Hash, Eq, PartialEq, Encodable, Decodable)]
pub struct AbsoluteBytePos(u64);

impl AbsoluteBytePos {
    #[inline]
    pub fn new(pos: usize) -> AbsoluteBytePos {
        AbsoluteBytePos(pos.try_into().expect("Incremental cache file size overflowed u64."))
    }

    #[inline]
    fn to_usize(self) -> usize {
        self.0 as usize
    }
}

#[derive(Encodable, Decodable, Clone, Debug)]
struct EncodedSourceFileId {
    stable_source_file_id: StableSourceFileId,
    stable_crate_id: StableCrateId,
}

impl EncodedSourceFileId {
    #[inline]
    fn new(tcx: TyCtxt<'_>, file: &SourceFile) -> EncodedSourceFileId {
        EncodedSourceFileId {

View on GitHub (pinned to 22057b88b0)

Solutions

  1. Delete the incremental cache and rebuild: `cargo clean && cargo build`.
  2. Inspect the failing crate's `target/<triple>/incremental/` for the corrupted `.rlib`/cache file and remove just that file.
  3. Disable incremental compilation: `CARGO_INCREMENTAL=0`.
  4. Check disk health / free space and ensure no process is truncating `target/` mid-build.
  5. Report to rust-lang/rust if it persists after a clean build, attaching `rustc -vV`.

Example fix

# before
$ cargo build   # panic: Incremental cache file size overflowed u64.

# after
$ rm -rf target/<triple>/incremental
$ cargo build   # rebuilds the cache from scratch
Defensive patterns

Strategy: validation

Validate before calling

// Validate that the on-disk incremental cache has not grown pathologically large
// before invoking cargo, so the u64-size overflow cannot be hit.
use std::path::Path;
fn incremental_cache_size_ok(target_dir: &Path, limit_bytes: u64) -> bool {
    let Some(target) = target_dir.canonicalize().ok() else { return true; };
    let inc = target.join("debug").join("incremental");
    if !inc.exists() { return true; }
    let mut total: u64 = 0;
    let mut stack = vec![inc];
    while let Some(dir) = stack.pop() {
        let Ok(rd) = std::fs::read_dir(&dir) else { continue };
        for entry in rd.flatten() {
            let p = entry.path();
            if p.is_dir() { stack.push(p); }
            else if let Ok(m) = entry.metadata() { total = total.saturating_add(m.len()); }
        }
    }
    total < limit_bytes // e.g. 4 GiB ceiling; prune if exceeded
}

Prevention

When it happens

Trigger: Reached only if some encoder computes a byte position whose `usize` value exceeds `u64::MAX`—impossible for legitimate files but theoretically reachable if a length field is read from a corrupted/truncated cache file and interpreted as an enormous offset, or if an internal arithmetic bug produces a wraparound value that happens to land above `u64::MAX` on a platform where `usize` is 128-bit (none exist today).

Common situations: Practically never seen in the wild. The realistic path is a corrupted incremental-cache file (disk error, NFS oddity, interrupted write) feeding garbage offsets into the encoder, or a hypothetical future 128-bit `usize` platform with a buggy length computation. Normal users should treat any sighting as cache corruption.

Related errors


AI-assisted analysis of rust-lang/rust@22057b88b0 (2026-08-03). Data as JSON: /data/errors/0bd50ddeb527865a.json. Report an issue: GitHub.