`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