[GHC] #15481: TH fails to recover from reifyFixity with -fexternal-interpreter

[GHC]

#15481: TH fails to recover from reifyFixity with -fexternal-interpreter
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Template Haskell  |              Version:  8.4.3
      Resolution:                    |             Keywords:  RemoteGHCi
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by simonpj):

 * cc: simonmar (added)


Comment:

 Generally, in GHC's type checker monad we can

 1. Add an error into a bag of errors to be reported later
 2. Raise an exception in the monad

 (1) and (2) are independent:

 * You can add an error without raising an exception, via `addErrTc`,
   thereby allowing multiple errors to be reported.

 * You can add an error and raise an exception; that's what `failTc` does.

 * You can raise an exception without adding an error; but that would
   be very confusing and GHC never does that.

 The expected behaviour of `Language.Haskell.TH.recover` is, I believe,
 that it should invoke the recovery action if either (1) or (2) has
 happened; that is, even if execution finishes without raising an
 exception,
 but with errors in the error bag, we should invoke the recovery action.

 And indeed that is what happens:

 * `Language.Haskell.TH.recover` invokes `qRecover` in the `Quasi` monad.
 * The instance for `Quasi TcM` in `TcSplice` has
 {{{
   qRecover recover main = tryTcDiscardingErrs recover main
 }}}
 * And indeed `tryTcDiscardingErrors` invokes the recovery action
   if there are accumulated error messages, even if no exception is
   raised.

 So it must be something to do with the external interpreter.  Let's
 fix that, rather than messing with the entirely-innocent `qReifyFixity`.

 Simon M, any ideas?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15481#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler