#14788: `error` in GHC internals can disappear by rerunning ghc again -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #14533 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was messing around with GHC's source code and thus triggered a bug, manifesting in my case as the `pprPanic "applyTypeToArgs" panic_msg` in `applyTypeToArgs` in GHC 8.2.1. Expectedly, ghc died with `the 'impossible' happened` while compiling a package (in my case `vector`). With output like this (it's not important to read the output in detail, only to see the `.o` file involved): {{{ [17 of 21] Compiling Data.Vector.Storable.Mutable ( Data/Vector/Storable/Mutable.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.2/build/Data/Vector/Storable/Mutable.o ) Data/Vector/Storable/Mutable.hs:77:1: warning: [-Wunused-imports] The import of ‘Foreign.Ptr’ is redundant except perhaps to import instances from ‘Foreign.Ptr’ To import instances alone, use: import Foreign.Ptr() | 77 | import Foreign.Ptr | ^^^^^^^^^^^^^^^^^^ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): applyTypeToArgs Expression: n#_aKi p_a3X ds5_XM4 ds7_aKj x#_aKa eta_X1H Type: Int# Args: [p_a3X, ds5_XM4, ds7_aKj, x#_aKa, eta_X1H] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreUtils.hs:226:14 in ghc:CoreUtils }}} What I did not expect was that by rerunning my `ghc --make` invocation again, the error would disappear! This is because after the error, the `.o` file is corrupt, just cut off in the middle. The reason is probably that GHC writes the `.o` file contents from an expression that can contain `error` thunks deep in, so the error only surfaces in the middle of the writing. As a result, the `.o` file is touched and `ghc --make` build pipeline, when resumnig the build next time, thinks that the `.o` file was completed all fine. I think `ghc --make` should not write the `.o` file when there's an obvious error. I suggest that ghc either `deepseq` the string to be written to the `.o` file before calling `writeFile` or equivalent, or write the file to an `.o.tmp` file and rename the temp file upon completion. The latter approach would also help against corrupted files due to power loss, see #14533. Fixing this would make developing GHC easier, as right now you can accidentally continue from a completely broken state (corrupt `.o` file) and only notice the error much later and then have to backtrack. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14788 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler