[GHC] #15272: Handle implied flags more intuitively

[GHC]

#15272: Handle implied flags more intuitively
-------------------------------------+-------------------------------------
           Reporter:  tdammers       |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:  8.6.1
          Component:  Compiler       |           Version:  8.4.3
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  Other
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:  #14963
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Many flags in GHC imply other flags. For example, enabling `-fdefer-type-
 errors` also enables `-fdefer-type-holes` and `-fdefer-out-of-scope-
 variables`:

 {{{
 GHCi, version 8.4.2: http://www.haskell.org/ghc/  :? for help
 Prelude> :set
 options currently set: none.
 base language is: Haskell2010
 with the following modifiers:
   -XNoDatatypeContexts
   -XNondecreasingIndentation
 GHCi-specific dynamic flag settings:
 other dynamic, non-language, flag settings:
   -fignore-optim-changes
   -fignore-hpc-changes
   -fimplicit-import-qualified
 warning settings:
 Prelude> :set -fdefer-type
 -fdefer-type-errors  -fdefer-typed-holes
 Prelude> :set -fdefer-type-errors
 Prelude> :set
 options currently set: none.
 base language is: Haskell2010
 with the following modifiers:
   -XNoDatatypeContexts
   -XNondecreasingIndentation
 GHCi-specific dynamic flag settings:
 other dynamic, non-language, flag settings:
   -fdefer-type-errors
   -fdefer-typed-holes
   -fdefer-out-of-scope-variables
   -fignore-optim-changes
   -fignore-hpc-changes
   -fimplicit-import-qualified
 warning settings:
 }}}

 This is fine.

 Disabling previously enabled flags does not disable the implied flags:
 `-fno-defer-type-errors` does not also set `-fno-defer-type-holes` and
 `-fno-defer-out-of-scope-variables`. This is also fine in principle;
 otherwise, setting `-fdefer-type-holes -fno-defer-type-errors` would do
 the unintuitive thing of setting neither flag.

 But it does lead to unintuitive behavior when the implied flags have never
 been touched explicitly: setting `-fdefer-type-errors`, and then later
 `-fno-defer-type-errors`, leaves `-fdefer-type-holes` and `-fdefer-out-of-
 scope-variables` set, even though the user never asked for them:

 {{{
 Prelude> :set -fdefer-type-errors
 Prelude> :set
 options currently set: none.
 base language is: Haskell2010
 with the following modifiers:
   -XNoDatatypeContexts
   -XNondecreasingIndentation
 GHCi-specific dynamic flag settings:
 other dynamic, non-language, flag settings:
   -fdefer-type-errors
   -fdefer-typed-holes
   -fdefer-out-of-scope-variables
   -fignore-optim-changes
   -fignore-hpc-changes
   -fimplicit-import-qualified
 warning settings:
 Prelude> :set -fno-defer-type-errors
 Prelude> :set
 options currently set: none.
 base language is: Haskell2010
 with the following modifiers:
   -XNoDatatypeContexts
   -XNondecreasingIndentation
 GHCi-specific dynamic flag settings:
 other dynamic, non-language, flag settings:
   -fdefer-typed-holes                <- These two are
   -fdefer-out-of-scope-variables     <- unexpected!
   -fignore-optim-changes
   -fignore-hpc-changes
   -fimplicit-import-qualified
 warning settings:
 }}}

 So we have a conundrum: when unsetting a flag, we may or may not need to
 unset the options it implies - neither is always correct, so in order to
 figure out what to do, we need to know *why* the flag was set. But it's
 even worse: if we have a flag X, and two other flags A and B, both of
 which imply X, and we first set A and B, and then unset B, we would have
 to keep X set, because otherwise we would break A. But if we then also
 unset A, we would have to also unset X. Tracking which option implicitly
 enabled which other option, and correctly resolving that, seems like
 terribly messy business. So I propose a different solution:

 1. Maintain one set of `DynFlags` that holds only those flags that were
 requested explicitly. Setting `-fdefer-type-errors` would only set
 `Opt_DeferTypeErrors` in this set, but none of the implied flags; and
 `-fno-defer-type-errors` would simply unset `Opt_DeferTypeErrors`.
 2. Maintain another set of `DynFlags` that holds the effective flags: we
 can always calculate these based on the explicit flags. We could either do
 this on the fly, just before running the actual compilation / evaluation,
 or we could keep the data structure around and only update it when the
 explicit flags have changed.

 This way, setting and unsetting flags will always do the right thing, and
 we don't throw away the information about which flags were set explicitly.


 This is probably more relevant in GHCi, because in plain GHC, one would
 typically just set all the needed flags at once and then never change them
 again until the next run; but in GHCi, modifying compiler flags between
 evaluations is a common thing to do.

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