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

[GHC]

#14963: ghci -fdefer-type-errors can't run IO action from another module
-------------------------------------+-------------------------------------
        Reporter:  elaforge          |                Owner:  tdammers
            Type:  bug               |               Status:  patch
        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:
                                     |  ghci/should_run/T14963
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4833
       Wiki Page:                    |  Phab:D4830
-------------------------------------+-------------------------------------

Comment (by tdammers):

 Quick thought on the side: `-fdefer-type-errors` currently implies
 `-fdefer-type-holes` and `-fdefer-out-of-scope-variables`, which makes
 sense; however, the way implied flags currently work in GHC leads to
 unexpected results in GHCi when you turn a flag on and then off again.
 You'd expect `:set -fdefer-type-errors; :set -fno-defer-type-errors` to be
 a no-op, but it's not, because it turns `-fdefer-type-holes` and `-fdefer-
 out-of-scope-variables` on and never off again.

 So my thought was that maybe it would be better to use two sets of
 `DynFlags` here: one set to represent what the user explicitly requested,
 not setting any of the implied flags; and one set of "effective" flags,
 containing the explicitly requested ones plus all the implied ones. The
 latter would be calculated on the fly, just before compiling, based on the
 former. This way, we can trivially tell the difference between flags
 explicitly requested by the user, and flags that are active because some
 other flag implies them, and unsetting the explicit flag will take the
 implicit flags with it unless they were also requested explicitly.

 If people think this would make sense, I'll file it as a separate ticket.

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