Cargo does not rebuild if project got changed in the same second #5918
Description
To reproduce, take a small crate (I am using https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks/coercions), and run
cargo +nightly build # fill incremental cache
for i in $(seq 1 10); do touch src/main.rs && cargo +nightly build; done
These should give fairly consistent timings. However, they do not:
Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
Finished dev [unoptimized + debuginfo] target(s) in 0.72s
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
Finished dev [unoptimized + debuginfo] target(s) in 0.70s
Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
Finished dev [unoptimized + debuginfo] target(s) in 0.71s
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
Finished dev [unoptimized + debuginfo] target(s) in 0.70s
Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
Finished dev [unoptimized + debuginfo] target(s) in 0.69s
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
Finished dev [unoptimized + debuginfo] target(s) in 0.70s
Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
Finished dev [unoptimized + debuginfo] target(s) in 0.70s
As you can see, it does not even recompile the project each time! Seems like it is (a) using a one-second granularity, and (b) if the last change and the last build happened in the same second, it assumes the build was first! The latter is a wrong assumption, leading to this bug.