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

 Replying to [comment:10 simonmar]:
 > Why not instead extend the current mechanism to add non-determinism in
 the code generator?

 From my side it's just a limitation of how much time I can sink into it.

 Making uniques not surface at all in the generated code would be great and
 cover more use cases, like being able to switch between `-c` and `--make`
 as you say, but an approach like I suggest would already cover the most
 common use cases (e.g. libraries and binaries built by cabal, Stack, Linux
 distributions would be deterministic, as they all use `--make`, and `[TH]`
 recompilation would be reduced), while (to my knowledge) not regressing
 any existing functionality (switching between `--make` and `-c` would
 remain as determinism-destroying as they were so far).

 Also, the two approaches don't seem to be competing -- it appears to me
 that in an ideal world, GHC would have neither internal variables appear
 in outputs, nor use any form of module-spanning "impure" internal state
 driven by `unsafePerformIO` as it has now.

 Using the module index is a quickest-and-easiest way to map the modules
 into a compact range of integers for easy array indexing. If this turns
 out to not be relevant for performance, then I could imagine also using
 the fully qualified module name or something similar, which might address
 the `-c` vs `--make` issue.

 > Relying on unique determinism is quite fragile and easily broken, and we
 have no way to know when that happens - at least with the current scheme
 we have some protection in the APIs for things like `UniqFM` so that it's
 hard to accidentally introduce non-determinism.

 I'd argue that removing the possibility to access an
 `unsafePerformIO`-based number generator at all would be a much stronger
 guarantee that non-determinism cannot be introduced, is that not accurate?

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