Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove `Freshness` from `DependencyQueue` #6832
Ever since the inception of Cargo and the advent of incremental
The previous model relied upon implicitly propagating "dirtiness" based
Implicit propagation of whether a unit is fresh or dirty is no longer
Note that this required a good deal of work on the
(This looks great, btw.)
I think I see why
Previously it was only keeping a
With this, the
I'm not sure what a good fix would be. Maybe
Could also maybe disable the
Ah right yeah that makes sense. So this is where we relied on dirty propagation through the dependency queue to correctly recompile libraries after the build script ran. With that removed we regained that feature by tracking hashes, but the hashes are too brittle here. Both before and after we correctly deduce that the hash of a build script run has changed but it doesn't need to be recompiled after
TBH I found it very difficult to grapple with how the
I think a better solution to this might be to completely remove mtime information from hashes. In theory all fingerprints should be 'this file relative to that file', and I wonder if we can do dirty propagation in the initial computation of the
referenced this pull request
Apr 9, 2019
Alright well it's not a patch to fingerprints in Cargo unless it touches more than 1kloc!
I believe all tests should be passing now. The general strategy I settled on was to basically ban
This should neatly solve the docker case and did indeed naturally fix it quickly! It did result in some more invasive refactorings though which are all here now.
So this should now be good to go!