Re: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module

11 Jun 2018

      #14963: ghci -fdefer-type-errors can't run IO action from another module
-------------------------------------+-------------------------------------
        Reporter:  elaforge          |                Owner:  tdammers
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.4.2
       Component:  GHCi              |              Version:  8.4.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 I've done some more dumping. The situation can be traced back to the
 desugar phase at least.

 In all 4 test cases, I did the same thing:

 - start up `ghci` on the `Foo.hs` module, with `-fforce-recomp -ddump-ds
 -dsuppress-all`; adding `-fdefer-type-errors` or not depending on the test
 case.
 - depending on the test case, `:set -fno-defer-type-errors` or `-fdefer-
 type-errors` to override the command-line setting
 - evaluate `test` in `ghci`

 It turns out that the desugared output is almost entirely identical (save
 for mismatching Uniques), except for the final GHCI invocation of `test`.
 The desugared output for that is identical between the three cases that
 involve deferred type errors anywhere, but different for the case that
 doesn't defer type errors anywhere. To wit:

 With deferred type errors in either or both module compilation and
 interactive
 session:
 {{{
 ==================== Desugared ====================
 bindIO
   (let {
      $dShow_a1Rt
      $dShow_a1Rt = $fShowInt } in
    (\ @ a_a1Dg ->
       let {
         $dGHCiSandboxIO_a1Di
         $dGHCiSandboxIO_a1Di = $fGHCiSandboxIOIO } in
       ghciStepIO $dGHCiSandboxIO_a1Di)
      test)
   (\ it_a1CU ->
      thenIO
        (print $dShow_a1Rt it_a1CU)
        (returnIO (: (unsafeCoerce# it_a1CU) [])))
 }}}

 Without deferred type errors:
 {{{
 ==================== Desugared ====================
 let {
   $dShow_a1Rq
   $dShow_a1Rq = $fShowInt } in
 bindIO
   ((\ @ a_a1De ->
       let {
         $dGHCiSandboxIO_a1Dg
         $dGHCiSandboxIO_a1Dg = $fGHCiSandboxIOIO } in
       ghciStepIO $dGHCiSandboxIO_a1Dg)
      test)
   (\ it_a1CT ->
      thenIO
        (print $dShow_a1Rq it_a1CT)
        (returnIO (: (unsafeCoerce# it_a1CT) [])))
 }}}

 Ignoring uniques entirely, the only real difference is whether or not the
 `dShow...` binding is floated out.

 So the questions are: why does it get floated out when type errors are
 deferred; and how does that lead to GHC calling `nameModule` on the
 `dShow...` part.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14963#comment:28
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler