[beta-1.92] fix: force update mtime of cargo-check artifacts #16273
Conversation
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
added
A-build-execution
|
|
Has this gotten any testing on nightly, yet? I'm a little nervous about unexpected problems like #6573 (touching the mtime on every crate caused a massive regression in Docker). This doesn't look like it will hit that particular case (since it seems to only be modifying the mtime on build), but it's hard to predict what consequences this might have. In particular, modifying the mtime with (For the record, I think this is something that should be fixed in rustc instead. This is fine to do here, but I hope it is temporary.) |
|
It is fairly new so data is insufficient. If there is a concern, we should cancel this backport. Backport should not be risky. |
|
A less risky backport would be to disable incremental compilation |
weihanglo
added
S-blocked-external
4 participants
Beta backports
In order to make CI pass, the following PRs are also cherry-picked: