Switching GHC's recompilation checker from interface-hash to full-content hashes: compatibility implications

Short answer

Probably not as a default. GHC's interface-hash recompilation checker is a deliberate design that already provides sound incremental correctness for ABI-relevant changes. Switching to full-content hashing would mostly add rebuilds, not soundness: any edit to a dependency's source — including comments, formatting, or internal refactors that never touch the compiled interface — would invalidate all reverse dependencies. There is no published, community-agreed benchmark quantifying the average rebuild-time increase or spurious recompilation rate, so any specific percentage would be speculative until measured on your own projects.

Likely explanation vs. confirmed facts

Confirmed by design: GHC's --make mode compares hashes of module interface files (.hi), which capture the ABI-relevant surface: types, unfoldings, strictness annotations, and instances. A source change that leaves the interface unchanged does not recompile dependents. This is intentional recompilation avoidance, not a correctness gap.

Likely, but unverified quantitatively: the cost of a content-hash scheme is workload-dependent. Projects with wide dependency fan-out — many modules importing a common utility module — would see the largest amplification, because each benign edit to a low-level module invalidates everything downstream. Known correctness gaps in interface hashing (orphan instances, file-embedding primitives like Template Haskell file I/O, non-deterministic output) are not fully fixed by content hashing either, which undercuts the main motivation for the switch.

Answers to the three sub-questions

Average rebuild-time increase

No reliable figure exists. It scales with reverse-dependency fan-out and edit patterns, and varies by GHC version. The honest answer is: measure it. A controlled experiment is feasible:

# Baseline: build deps, then make a benign edit (comment/formatting)
cabal build --only-dependencies
cabal build
# edit a low-level module's comment, then:
cabal build   # count recompiled modules

Compare the rebuild count against a prototype content-hash invalidation on the same tree. Use -ddump-hi-diffs to see which interface differences actually trigger rebuilds under the current checker.

Spurious recompilation frequency

Under content hashing, every non-ABI change to a module spuriously invalidates its dependents by definition. How often that occurs equals your rate of non-ABI edits to shared modules — a project-property, not a GHC-property. Interface hashing exists precisely to suppress this class of rebuild.

Migration for Cabal stores and Stack snapshots

Largely a non-issue, with one caveat. Cabal and Stack identify installed packages by unit IDs derived from the package configuration and dependency hashes — not by GHC's internal recompilation checker — so changing the checker would not by itself invalidate existing store entries or snapshots. The caveat: any tool that incorporates GHC interface hashes into its own cache keys would need a coordinated update, and unit-ID computation is version-sensitive. A flag-gated rollout (opt-in per GHC version) would avoid mass cache misses; flipping the default without a transition period would not break stores, but would change rebuild behavior silently across mixed-version teams.

Recommendation

The safer direction, consistent with discussions in the GHC ecosystem, is improving interface-hash precision — finer-grained dependency tracking, deterministic interface files — rather than wholesale replacement with content hashing. Before proposing a default change, check the GHC user's guide and release notes for your specific version and review the issue tracker on recompilation avoidance, since behavior and consensus shift across releases.