Comment by tancop
1 hour ago
You dont need to rehash everything if you do multi level hashing (file -> mod/impl block -> function). The expensive part is doing lots of hash passes over small parts of a file, so if you break as early as possible the moment you can guarantee that part is unchanged you save a lot of time. And if you assume (and document) that libraries need to be rebuilt manually you can completely skip checking them.
OP handles the small change problem by hashing IR instead of source text. If the new function compiles to the same IR as the old one its guaranteed to give the same machine code. You should repeat this after each lowering or optimization pass so functions with different HIR but same MIR are also marked as unchanged and dont cause items up the tree to rebuild.
> OP handles the small change problem by hashing IR instead of source text
OP here---I think you got confused somewhere, because this isn't true! The hashes we take are of source code, they're just stored inside of the first IR. Source code is just pretty convenient to hash. If the change does turn out to be something trivial, we'll only invalidate the first-order dependencies of the source hash, which is never usually a big deal. In a particularly bad case, maybe we re-analyze, re-codegen, and re-link many different instances of a generic function, but even that wouldn't usually take long at all.
Also, it's actually important that we do notice these kinds of "trivial" changes in some parts of the pipeline---see Andrew's comment [0] on the Lobsters discussion for this post.
[0]: https://lobste.rs/s/rmzzdb/inside_zig_s_incremental_compilat...