Cargo check (via rust-analyzer) forcing full rebuilds.

[497e0bdf29873]

Problem

I'm running into the issues described in rust-lang/rust-analyzer#17155, and first attributed to rust-analyzer, but have myself traced it down to cargo check.

Basically, cargo check seems to cause changes in file time stamps (that cargo build itself does not cause!), and this causes cargo build to fully rebuild unmodified (*-sys type) sub-crates and run build.rs, unnecessarily. This makes it pretty much impossible to run rust-analyzer.

Steps

If I edit and save a file in Zed, which runs rust-analyzer and through it, cargo check, a cargo build in the terminal will always be full (of the project and sub-crates, not of external dependencies).

If I edit the same file in a simple editor like joe, which doesn't know anything abour rust-analyzer and cargo, only the necessary components will be rebuilt by cargo build.

But I can even remove the editor out of the equation: If

1. I run cargo check, without even touch any file,
2. a subsequent cargo build will be a full rebuild.
3. However, a cargo build followed by a cargo build, will do nothing.

So there's something weird going on with cargo check.

Possible Solution(s)

No response

Notes

I suspect relationship to #10175 and #15073.

Version

cargo 1.89.0-nightly (056f5f4f3 2025-05-09)
release: 1.89.0-nightly
commit-hash: 056f5f4f3c100cb36b5e9aed2d20b9ea70aae295
commit-date: 2025-05-09
host: aarch64-apple-darwin
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.7.1 (sys:0.4.80+curl-8.12.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.4.1 11 Feb 2025
os: Mac OS 15.4.1 [64-bit]

[497e0bdf29873]

An additional detail: cargo check after cargo check is ok, as is cargo build after cargo build, but one after the other will always run a full rebuild and the build script.

This only happens to me in a crate with xxx = { path = xxx-sys } sub-crates, as well as cxx and pyo3 components. Based on that, I would suspect that the environment would change between build and check, and one of those crates would have some sort of cargo:rebuild-if-env-changed=everything-possible setting in them. However, CARGO_LOG=cargo::core::compiler::fingerprint=info only shows timestamp changes as reasons for the rebuilds, and mentions nothing about those two crates, only about sub-crates.

[weihanglo]

Is it a full rebuild or rebuild from that sys crate? Also, are you using Nix? I have an assumption that one cargo::rerun-if-changed pointed to a directory and cargo doesn't preserve the timestamp for directories.

Would be great if you manage to minimise and provide a repro for us :)

[497e0bdf29873]

Ok, here's the most minimal example I could create. Despite having no real content and no external dependencies, it's quite convoluted:

• Two “sys" crates.
• One “sys” crate depends on the other
• The build script of the main one also depends on one.
• The sys-crates have crate-type = ["dylib", "rlib"]

Remove any of these, and the check-build race condition goes away.

Since build-print output is not dependable (it seems to be shown even if the build scrip is not run), I'm using 5 second delay in each build.rs to observe the effect of them being run.

(In the real situation, not this example, the “sys” crate that the other one depends on is not really a sys crate but a proper crate of Conda helpers for the build scripts of other two real sys crates, fenics-sys and nanobind-sys—because Fenics is distributed through Conda.)

cargo-bug.zip