> This is provably impossible to make usefully incremental. The encryption can be implemented as a graph of function calls, and you can apply the general incremental recipe to it. It just won’t be very fast.

The specific example is bogus.

Merkle trees and their many variants exist to solve precisely this problem.

For more compiler-specific scenarios there exist vaguely similar solutions to the issues introduced by incremental compilation such as splitting up monolithic executables into many small dynamically loaded libraries (only during development time), or taking that to the extreme, hot code reloading at the function level.

> ... only because Zig language is carefully designed to allow this.

Is the key point. Rust wasn't designed for incremental compilation, and most legacy languages like C only allow it in a useful way because they were designed in the era "kilobytes" of system memory and hence they're very frugal in their design.

Other than Zig, the only modern language I'm aware of that was "co-designed" for efficient compilation and incremental reload is Jai.

> Expanding macros requires name resolution, which, in Rust, is a crate-wide, rather than a file-wide operation.

Sure, but macros change infrequently, so that ought to be a highly cacheable pure function for most edits.

> The above scheme works only if the language has a property that changing the body of function foo (not touching its signature) can’t introduce type errors into an unrelated function bar.

AFAIK Rust and most other statically typed languages have this property. Optimisations such as inlining can mess with the cacheability of code-gen in all languages.