Don't hash FileTime value in PathSource::fingerprint

[alexcrichton]

Currently here in Cargo we will insert the FileTime value, stringified, into a Fingerprint for a package. This is only ever used for build scripts which do not mention rerun-if-* directives.

Hashing FileTime is particularly brittle because filesystems are weird. The primary use case today is that Docker will rewrite file times to zero out the nanosecond field. This means that the hash for a build script changes between docker, even though nothing actually changed.

We should instead thread through the set of files considered input to a build script to the Fingerprint. These files would then be stored in the Fingerprint (and deterministically hashed) where we would later determine at runtime what the FileTime modification time is for each file for recompilation purposes.

I'm spawning this off of #6832 for a separable unit of work. We'll know this is fixed when this test has its branch on already_zero removed, because we should always consider everything fresh.

[fluffysquirrels]

Sorry if this is obvious, but should we hash source files to check freshness only when their modified time has changed? Otherwise we would need to re-hash all source files for path dependencies on every null build, correct? That seems like it might hurt null build performance.

In case it helps, I believe Git only rehashes files when their modified time (stored in the index) is changed.

I'm happy to take a look at this; would a PR be useful?

[alexcrichton]

Hashing the contents of files is definitely something we're interested in exploring! That's tracked at #6529 and you're right in that it's not initially done because of performance reasons, but using a combination of mtime + content hash seems not entirely unreasonable.

[alexpyattaev]

Scons uses content hash successfully for years now, and works faster than most build systems for c++.