rustc does not always update the mtime of all its outputs

[RalfJung]

There are apparently situations involving incremental compilation where rustc will conclude that an output file (e.g. an rmeta file) is already fully up-to-date, and will just not do anything to it. However, build systems (including cargo) typically assume that they can use the mtime to figure out whether an output is up-to-date, so rustc not bumping the mtime of an output can lead to confusion.

We may want to fix rustc so that it always bumps the mtime of its outputs, even if they need no other changes. That should be quite cheap to do, and can avoid a lot of downstream head-scratching such as:

• #t-infra/bootstrap > spurious rebuilding of rustc_llvm @ 💬
• If an empty build script's output's mtime is newer than the build script binary, it's always considered to be dirty cargo#16104

[RalfJung]

Apparently rustc started doing this with #114669.
Cc @cjgillot @petrochenkov

[RalfJung]

Quoting @bjorn3's comment from elsewhere

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.

[weihanglo]

Do we expect to get a fix of this timely, and perhaps have a beta-backport?

Cargo team was considering a beta-backport of rust-lang/cargo#16262, so compiler developers won't be affected by this. If on compiler side we don't, I'll submit a Cargo beta-backport PR.

[apiraino]

Assigning priority (discussion on Zulip).

@rustbot label -I-prioritize +P-high