(Ignore the quality of the PR - it's WIP, focus for now on the intent)
I'm keen on speeding up the compiler by not compiling at all.
I'm working on a rustc/cargo PR ( https://github.com/rust-lang/rust/pull/75594 , https://github.com/rust-lang/cargo/pull/8623 ) to try and reduce our depedency on correct mtimes and I wanted a bit more visibility / debate on what I'm trying to do.
Problem: When mtimes work well they work really well. When they are upset by external processes cargo falls back to a full rebuild even though the content hasn't actually changed.
For the simple cases mtimes work nicely, but when dealing with more convoluted [corporate] situations mtimes have a hard time with:
- docker-like things with stashed layers stored at rounded precision.
- conda-build isolated environments
- other? I'm sure the above aren't the only way to mess up mtimes if we try hard enough!
Mtimes can't always be relied upon as things get moved about and unziped. It would be great if, even in those circumstances, cargo/rustc could still realise it didn't need to rebuild.
I don't want dodgy mtimes to stop me falling into the cached pit of success.
To this end we already hash all the source files and it seem sensible to record those already computed hashes and take advantage of them when checking whether a rebuild is needed in Cargo. (Potentially this PR is already a positive improvement on the status quo).
I'd like to do the same thing with binary dependencies and the suggestion is to add SVH to the output binaries by default so that we have a consistent hash to compare against. It will take a bit of platform dependent fishing to extract it out again, but it should be considerably faster than hashing a file potentially large binary file.
Anyway as it's a bit more of an adventurous PR than anything I've done before so I thought I'd get a few more eyes and minds on it.