[GHC] #14769: The RecompBecause [TH] check is not resume-build-safe

[GHC]

#14769: The RecompBecause [TH] check is not resume-build-safe
-------------------------------------+-------------------------------------
        Reporter:  nh2               |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #481              |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nh2):

 Yes, that scheme lacks "stability" against some use cases. Most
 prominently, adding a new module and importing it, thus turning e.g. `[1
 of 3]` into `[2 of 4]`, will have us end up with different uniques and
 thus different `.o` files and different binaries (and the benefit of
 reduced `[TH]` compilations is lost for such changes).

 But the scheme should still solve the most common use cases:

 * A from-scratch build using the same code and same compiler would result
 in byte-identical outputs
 * Resuming a `--make` (`-j`) build after merely touching a file or
 changing a comment would result in byte-identical outputs
 * Resuming a `--make` (`-j`) build after changing the code in a module
 will would result in only the `.o` for that module to change (plus
 potentially some inlining sites if `-O` is on); `.o` files that were
 recompiled because of `[TH]` that generate identical `.o` outputs will
 allow for the identical-.o-file-`[TH]`-avoidance you proposed above

 The first point will allow us to get byte-reproducible binaries ala
 Debian's "reproducible builds"; until now due to Unique nondeterminism,
 this wasn't possible even under guaranteed input control and stopping-the-
 system-time sandboxes, as Nix does it.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14769#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler