"cargo test" not noticing file changes

[ChrisJefferson]

Problem

I run a script (attached below) on a repository, which changes various source files. After this script is run, cargo test reports failure unless I "touch" a source file, at which point it notices files have changed and the tests pass. While the stuff I'm doing is fairly stupid, I don't think I'm doing anything that horrible, so I'd expect cargo test to notice the changed files?

Steps

1. clone https://www.github.com/peal/vole, commit 8ce8ff37366e8bd
2. Go into the "rust" subdirectory.
3. Run cargo test, notice it works fine.
4. Run the following bash snippet:

for i in 19 33; do
    sed -i.old "${i}s/pub//" "src/perm/mod.rs"; (cargo check && cargo test); mv "src/perm/mod.rs.old" "src/perm/mod.rs"
done

This remove 'pub' in two places in "src/perm/mod.rs", then puts the old file back.
5. Run cargo test, notice it fails
6. Run git diff, notice it says no changes
7. Run touch src/perm/mod.rs, then cargo test, now cargo test passes.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.61.0 (a028ae4 2022-04-29)
release: 1.61.0
commit-hash: a028ae42fc1376571de836be702e840ca8e060c2
commit-date: 2022-04-29
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: Ubuntu 22.04 (jammy) [64-bit]

[epage]

#8868 includes a lot of diagnostic steps that would be helpful in determining what is going wrong.

Something to keep in mind is we currently use mtime (#6529) and that sub-second mtimes don't seem to be used (#5918).

#2904 is about making it easier to get rebuild reasons

[ChrisJefferson]

Here is a gist, I'm not totally sure how to interpret it -- from my initial scan it does seem to notice the file is out of date and has to rebuild the program, but then doesn't rebuild the tests? https://gist.github.com/ChrisJefferson/60ab4a82be6bb799a9fc3ae05a86ea68 However, if cargo doesn't do sub-second times, then all this could well be happening faster than a second and that would explain things.

[weihanglo]

Or the mtime from the restored file is actually older then referenced mtime from depinfo? There is a condition checking that. Could you check the mtime before touching it by something like stat -c %Y src/perm/mod.rs?

[ChrisJefferson]

Update: I put a "sleep 5" after each command, which didn't fix the problem. I switched the "mv" to "cp" which did.

The stat -c gave me the right direction -- the problem is I can mv does not update mtime. Therefore you can mv a random old file from your filesystem over any source file and cargo check and cargo test will (almost) not notice. The only way to fix that I can think of would be (a) hashing file contents, or (b) storing the inode. I imagine these have both been considered in the past?

The almost comes from the fact that Doc-tests seem to ignore the caching, so it notices when I mv a random file over a source file.

But, in the case I put in the gist, it's the other way around, doc-tests is picking up a stale file from somewhere, and the normal build is functioning correctly.

[weihanglo]

@ChrisJefferson Glad you figured it out! Your observation also matches what I remembered: rustdoc is not able to produce dep-info, so instead it precalculates fingerprints differently than normal units¹.

Anyway, I guess we could track alternative ways to detect file changes in #6529. I'll close this. Thank you for your findings!

Footnotes

1. https://github.com/rust-lang/cargo/blob/9bc91ff2a8b4edd1426a9f6d9dae059d48e17df6/src/cargo/core/compiler/fingerprint.rs#L210-L219 ↩