30% cargo target directory size regression between rust 1.96(.1) and 1.97(.1)

On our codebase (~1M LoC in a workspace with ~700 crates), we noticed a significant cargo target directory size regression after upgrading to Rust 1.97.1.

Examples of what we're observing:

• cargo build --bins --release with default optimization settings (there are no [profile.release] section in our Cargo.toml) and latest mold linker: increase from ~6GB to ~7GB.
• cargo nextest archive (which as I understand simply builds everything with all features in debug profile), with CARGO_INCREMENTAL environment variable set to 1 and RUSTFLAGS environment variable set to -C strip=debuginfo and necessary mold flags, and with debug = 0 in [profile.dev]: increase from ~62GB to ~79GB.
• cargo clippy --all-targets or cargo clippy --bins with CARGO_INCREMENTAL=1 and mold in RUSTFLAGS: no difference between 1.96.1 and 1.97.1 (at ~19GB and ~11GB respectively).

The results are very reproducible; just changing channel in rust-toolchain.toml between 1.96.1 and 1.97.1 (and cleaning cargo target directory so that it's empty) and re-running the command is enough to see the old or the new size. This also reproduces in a clean container based on rust:1.96.1-bookworm or rust:1.97.1-bookworm images (with regular libraries necessary for build installed from regular debian package repository).

Comparing two cargo target directories (for cargo nextest archive example) does not produce any insights; the directory structures are the same, and it's just that every file is suddely 20-50% larger on 1.97.1. debug directory is larger, everything in debug/deps is larger, and everything in debug/incremental/<crate_id>/<id> is larger (including dep-graph.bin and query-cache.bin).

Interestingly, archiving and compressing the target directory with ZSTD_CLEVEL=12 tar --zstd -cf ... produces archives of more or less the same size (~16.5GB), hinting that all that extra disk space used does not actually contain any significant amounts of new information; that the extra data is somewhat redundant from zstd point of view.

So I suspect that maybe this was caused by the change in https://github.com/rust-lang/rust/pull/151994 . Maybe with the new mangling scheme, somehow our identifiers are so large (and there are so many of them in the output) that on non-incremental release builds they contribute 15% to the size of cargo target dir, and on incremental builds, 30%?

I'm sorry that this is not a very detailed or specific information.

Version it worked on

It most recently worked on: 1.96.1

Version with regression

rustc --version --verbose:

rustc 1.97.1 (8bab26f4f 2026-07-14)
binary: rustc
commit-hash: 8bab26f4f68e0e26f0bb7960be334d5b520ea452
commit-date: 2026-07-14
host: x86_64-unknown-linux-gnu
release: 1.97.1
LLVM version: 22.1.6

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

Reproduce the target-directory size change by comparing clean Rust 1.96.1 and 1.97.1 builds with the cargo commands and flags listed in the report. Start by examining Rust PR 151994 and the size differences in debug, deps, and incremental artifacts. Done means identifying the cause of the larger files and providing a fix or focused regression evidence.