#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 simonmar): I'm very sceptical (in case you hadn't guessed!). @niteria spent a great deal of time removing cases of non-determinism from the compiler, so that we now have non-determinism at the ABI level. The way it's done currently is more robust than relying on unique determinism, because the compiler produces deterministic output even in the presence of unique non- determinism. 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'm really not keen on the idea of using the module index, because compiling a module individually with `-c` should produce exactly the same output as if it was compiled as part of a set of modules with `--make`. Why not instead extend the current mechanism to add non-determinism in the code generator? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler