`error` in GHC internals can disappear by rerunning ghc again
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
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-18.104.22.168/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.
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.