fix(fingerprint): force update mtime of cargo-check artifacts #16262

weihanglo · 2025-11-14T09:59:34Z

What does this PR try to resolve?

This mtime shift for .rmeta is a workaround as rustc incremental build
since rust-lang/rust#114669 (1.90.0) skips unnecessary rmeta generation.

The situation is like this:

When build script execution's external dependendies
(rerun-if-changed, rerun-if-env-changed) got updated,
the execution unit reran and got a newer mtime.
rustc type-checked the associated crate, though with incremental
compilation, no rmeta regeneration. Its .rmeta stays old.
Run cargo check again. Cargo found build script execution had
a new mtime than existing crate rmeta, so re-checking the crate.
However the check is a no-op (input has no change), so stuck.

Fixes #16104

How to test and review this PR?

Tests pass.

There is a reproduction in #16104 (comment),but actually a minimal one is touching a file of build script dependency, than cargo check. It'll easily get stuck.

This is an ugly workaround. And -Zchecksum-freshness doesn't help because build script is involved.

See rust-lang/cargo 16104 for what we're testing against

This mtime shift for .rmeta is a workaround as rustc incremental build since rust-lang/rust 114669 (1.90.0) skips unnecessary rmeta generation. The situation is like this: 1. When build script execution's external dependendies (rerun-if-changed, rerun-if-env-changed) got updated, the execution unit reran and got a newer mtime. 2. rustc type-checked the associated crate, though with incremental compilation, no rmeta regeneration. Its `.rmeta` stays old. 3. Run `cargo check` again. Cargo found build script execution had a new mtime than existing crate rmeta, so re-checking the crate. However the check is a no-op (input has no change), so stuck.

rustbot · 2025-11-14T09:59:39Z

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

epage · 2025-11-14T16:11:58Z

It would be nice for us to have a way to have early cut off but we can look into how to get both later

The next question is what to do about beta

backport
disable incremental compilation

Thoughts?

weihanglo · 2025-11-14T16:37:05Z

We probably want to backport to beta ASAP, as this affects rust-lang/rust developers.

epage

Sorry, doing this on mobile seemed to have failed me

View changes since this review

RalfJung · 2025-11-14T17:15:29Z

src/cargo/core/compiler/mod.rs

+        // 3. Run `cargo check` again. Cargo found build script execution had
+        //    a new mtime than existing crate rmeta, so re-checking the crate.
+        //    However the check is a no-op (input has no change), so stuck.
+        if mode.is_check() {


Wouldn't it make sense to do this for all modes?

I guess eventually we have to clarify the contract between rustc and cargo here: is rustc allowed to just do nothing if an output file is up-to-date, or is it required to always at least update the mtime?

I personally don't think rustc should care and update mtime.

keeping this patch small and suitable for backport, but yeah to be more robust and future proof, we probably want to do it for all modes, or at least adding tests to capture possible regression in a full cargo build.

Other build systems will probably get confused by the exact same issue, so perhaps this should actually be changed in rustc itself.

True, though OTOH a build system also shouldn't get into an internally inconsistent state (like what we saw in #16104) just because a tool it invokes has slightly odd behavior.

Make can't have any other behavior than continuous rebuilding as it doesn't store any information and only uses the mtime stored in the filesystem as would ninja I believe (which together with make are the main backends of cmake and which is the only backend of meson that supports Linux). Basically any mtime based build system (which is the fast majority of the build systems that are used) is broken when a build doesn't update the mtime of output files.

imo not updating on no difference in output is great in terms of early cut off. It is just getting all of the semantics right that is the issue.

Let's not discuss this in a closed PR... I have opened rust-lang/rust#148948.

weihanglo · 2025-11-18T01:51:55Z

Beta backport is filed: #16273.

Update cargo submodule 13 commits in 2d4fa139552ebdd5f091a1401ed03f7dc62cb43f..5c0343317ce45d2ec17ecf41eaa473a02d73e29c 2025-11-12 15:56:06 +0000 to 2025-11-18 19:05:44 +0000 - feat: emit a warning when both `package.publish` and `--index` are specified (rust-lang/cargo#16268) - docs(cargo-yank): clarify yank behavior with leaked credentials (rust-lang/cargo#16274) - feat(generate-lockfile): Add unstable --publish-time flag (rust-lang/cargo#16265) - Do not lock the artifact-dir for check builds (rust-lang/cargo#16230) - fix(fingerprint): force update mtime of cargo-check artifacts (rust-lang/cargo#16262) - fix(manifest): Point out when a key belongs to config (rust-lang/cargo#16256) - Use raw false during cfg test (rust-lang/cargo#16261) - Suppress metadata warnings for non–crates.io publishable packages (rust-lang/cargo#16241) - feat(tree): Support long forms for --format variables (rust-lang/cargo#16204) - fix(config): Fallback to non-canonical path for workspace-path-hash (rust-lang/cargo#16248) - fix: update mtime for generated files after unpacking (rust-lang/cargo#16250) - feat(cli): Add support for completing `--config` values in Bash (rust-lang/cargo#16245) - feat: Add a typos CI job (rust-lang/cargo#16122)

weihanglo added 2 commits November 14, 2025 04:52

test: cargo-check stuck due to build script mtime too new

2a07c68

See rust-lang/cargo 16104 for what we're testing against

rustbot assigned ehuss Nov 14, 2025

rustbot added A-build-execution Area: anything dealing with executing the compiler S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 14, 2025

weihanglo added the A-rebuild-detection Area: rebuild detection and fingerprinting label Nov 14, 2025

weihanglo mentioned this pull request Nov 14, 2025

If an empty build script's output's mtime is newer than the build script binary, it's always considered to be dirty #16104

Closed

epage enabled auto-merge November 14, 2025 16:12

epage approved these changes Nov 14, 2025

View reviewed changes

epage added this pull request to the merge queue Nov 14, 2025

RalfJung reviewed Nov 14, 2025

View reviewed changes

Merged via the queue into rust-lang:master with commit 745aae6 Nov 14, 2025
26 checks passed

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 14, 2025

RalfJung mentioned this pull request Nov 14, 2025

rustc does not always update the mtime of all its outputs rust-lang/rust#148948

Open

weihanglo deleted the rebuild branch November 14, 2025 17:54

weihanglo added the beta-nominated Nominated to backport to the beta branch. label Nov 14, 2025

weihanglo mentioned this pull request Nov 18, 2025

[beta-1.92] fix: force update mtime of cargo-check artifacts #16273

Open

weihanglo mentioned this pull request Nov 19, 2025

Update cargo submodule rust-lang/rust#149073

Merged

rustbot added this to the 1.93.0 milestone Nov 20, 2025

fix(fingerprint): force update mtime of cargo-check artifacts #16262

fix(fingerprint): force update mtime of cargo-check artifacts #16262

Conversation

weihanglo commented Nov 14, 2025

What does this PR try to resolve?

How to test and review this PR?

Uh oh!

rustbot commented Nov 14, 2025

Uh oh!

epage commented Nov 14, 2025

Uh oh!

weihanglo commented Nov 14, 2025

Uh oh!

epage left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

weihanglo Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

bjorn3 Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

bjorn3 Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

epage Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

weihanglo commented Nov 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

epage left a comment •

edited by rustbot

Loading