`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 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.
Trac metadata
Trac field | Value |
---|---|
Version | 8.2.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | nh2 |
Operating system | |
Architecture |