[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):

 > we don't have the information we really need, which is "did the object
 file change". Perhaps we just need to be more clever and store hashes of
 object files as dependencies when we're using TH

 @simonmar Exactly. I thought the same, and implemented that a couple days
 ago as a work-in-progress:

 https://github.com/ghc/ghc/compare/ghc-8.2.1-release...nh2:ghc-8.2.1
 -release-nonrecursive-recompBecause-TH?expand=1

 Would be nice if you could have a look, I can then work towards finishing
 that.

 In my preliminary experiments, this reduced the occurrance of the `[TH]`
 reason from 40 modules to 8 in a 150-module project.

 However, the big problem is still #12935, non-deterministic `.o` files. If
 they are nondeterministic, they will destroy object file hashing based
 recompilation avoidance.

 However, once it works, I think it will be great: With `-O0` I get
 (nondeterministically) a reduction from 40 modules to 1 module + relink.

 So I took a shot at that problem as well (making object files
 deterministic), taking a different approach than what was taken so far
 (instead of making uniques not appear in outputs, I'm trying to genrate
 them deterministically). In my small example it works up to a single
 difference in the final binary, but more work is needed.

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