[GHC] #14788: `error` in GHC internals can disappear by rerunning ghc again

10 Feb 2018

      #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