#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