1. 18 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      (Another) minor refactoring of substitutions · b5292557
      Simon Peyton Jones authored
      No change in functionality here, but greater clarity:
      
      * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
        We are already maintaining an in-scope set in the fe_subst field,
        so it's silly do to it twice.
      
        (This isn't strictly connected to the rest of this patch, but
        the nomenclature changes below affect the same code, so I put
        them together.)
      
      * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
        out what to do, but in fact we almost always know which of the
        two we are doing.  So:
          - define extendTvSubst, extendCvSubst
          - and use them
      
      * Similar renamings in TyCoRep:
         - extendTCvSubstList        -->   extendTvSubstList
         - extendTCvSubstBinder      -->   extendTvSubstBinder
         - extendTCvSubstAndInScope  --> extendTvSubstAndInScope
      
      * Add Type.extendTvSubstWithClone, extendCvSubstWithClone
      
      * Similar nomenclature changes in Subst, SimplEnv, Specialise
      
      * Kill off TyCoRep.substTelescope (never used)
      b5292557
  2. 11 Feb, 2016 1 commit
  3. 27 Jan, 2016 1 commit
  4. 26 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix two cloning-related bugs · 016a0bd1
      Simon Peyton Jones authored
      Crikey!  Not just one but two bugs in type variable cloning,
      both dating from the days before PolyKinds.  Both were shown up
      by Trac #11330.
      
      1. In SetLevels, when floating a case expression we must clone its
         binders, *and* do so in a telescope-aware way, because the
         constructor may bind a kind variable that appears in the kind
         of a type variable.
      
         Instead of doing this (wrongly) by steam, call CoreSubst.cloneBndrs.
      
         I added Notes and did other refactoring at the same time.
      
      2. It turned out that CoreSubst.cloneBndrs calls TyCoRep.cloneTyVarBndr,
         and that too was bogus!  It didn't substitute in the kind of the
         TyVar being cloned.  There was even a comment to say "variables can't
         appear in kinds".  Thta hasn't been true for a long time now.
      
      Easily fixed.
      
      Interestingly, I then found that test
         dependent/should_compile/KindEqualities
      was emitting a new inexhaustive-pattern-match warning.  Sure enough
      it was valid!  So the lack of cloning in cloneTyVarBndr really was
      causing an observable bug; just one that we had not observed.
      016a0bd1
  5. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  6. 16 Jan, 2016 1 commit
    • Alan Zimmerman's avatar
      Work SourceText in for all integer literals · 3a1babd6
      Alan Zimmerman authored
      Summary:
      Certain syntactic elements have integers in them, such as fixity
      specifications, SPECIALISE pragmas and so on.
      
      The lexer will accept mult-radix literals, with arbitrary leading zeros
      in these.
      
      Bring in a SourceText field to each affected AST element to capture the
      original literal text for use with API Annotations.
      
      Affected hsSyn elements are
      
      ```
           -- See note [Pragma source text]
           data Activation = NeverActive
                           | AlwaysActive
                           | ActiveBefore SourceText PhaseNum
                                -- Active only *strictly before* this phase
                           | ActiveAfter SourceText PhaseNum
                                 -- Active in this phase and later
                           deriving( Eq, Data, Typeable )
                                     -- Eq used in comparing rules in HsDecls
      
           data Fixity = Fixity SourceText Int FixityDirection
             -- Note [Pragma source text]
             deriving (Data, Typeable)
       ```
      
      and
      
      ```
            | HsTickPragma         -- A pragma introduced tick
               SourceText           -- Note [Pragma source text] in BasicTypes
               (StringLiteral,(Int,Int),(Int,Int))
                                                -- external span for this tick
               ((SourceText,SourceText),(SourceText,SourceText))
                  -- Source text for the four integers used in the span.
                  -- See note [Pragma source text] in BasicTypes
               (LHsExpr id)
      ```
      
      Updates haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1781
      
      GHC Trac Issues: #11430
      3a1babd6
  7. 07 Jan, 2016 1 commit
  8. 01 Jan, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Canonicalise `MonadPlus` instances · dafeb51f
      Herbert Valerio Riedel authored
      This refactoring exploits the fact that since AMP, in most cases,
      `instance MonadPlus` can be automatically derived from the respective
      `Alternative` instance.  This is because `MonadPlus`'s default method
      implementations are fully defined in terms of `Alternative(empty, (<>))`.
      dafeb51f
  9. 31 Dec, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Remove some redundant definitions/constraints · 3c8cb7f4
      Herbert Valerio Riedel authored
      Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`,
      which allows to simplify some definitions to exploit the superclass
      relationship. This a first refactoring to that end.
      3c8cb7f4
    • Simon Peyton Jones's avatar
      Improve exprIsBottom · 0579fe99
      Simon Peyton Jones authored
      This fixes Trac #11290, by being sligthtly cleverer about finding
      what expressions are bottom.  Actually this might have minor
      other side benefits.
      0579fe99
  10. 24 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Improve SimplUtils.interestingArg · 6ec236b5
      Simon Peyton Jones authored
      There were two problems here:
       - We were looking under a lambda without extending
         the in-scope env, which triggered a WARNING
         But there's no need to look under a lambda.
      
       - We were looking under a letrec without extending
         the in-scope env, which triggered the same WARNING
         Solution: extend the in-scope env
      6ec236b5
  11. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  12. 02 Dec, 2015 1 commit
  13. 29 Nov, 2015 1 commit
    • Ömer Sinan Ağacan's avatar
      Some improvements on CoreToDos passed to plugins · bcd55a94
      Ömer Sinan Ağacan authored
      This patch does two improvements:
      
      - We now show ToDos in `CoreDoPasses`. This is pretty important,
        otherwise `CoreDoPasses` makes debugging impossible in some cases.
      
      - Before running ToDos we run a cleanup pass on ToDos to remove
        `CoreDoNothing`s and flatten `CoreDoPasses`. This removes a lot of
        noise from `[CoreToDo]` argument passed to plugins.
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1548
      bcd55a94
  14. 25 Nov, 2015 1 commit
  15. 22 Nov, 2015 1 commit
    • niteria's avatar
      Make abstractVars deterministic in SetLevel · 6393dd8e
      niteria authored
      This fixes a non-determinism bug where depending on the order
      of uniques allocated, the type variables would be in a different order
      when abstracted for the purpose of lifting out an expression.
      
      Test Plan:
      I've added a new testcase that reproduces the problem
      ./validate
      
      Reviewers: simonmar, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: nomeata, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1504
      
      GHC Trac Issues: #4012
      6393dd8e
  16. 21 Nov, 2015 1 commit
    • niteria's avatar
      Create a deterministic version of tyVarsOfType · 2325bd4e
      niteria authored
      I've run into situations where I need deterministic `tyVarsOfType` and
      this implementation achieves that and also brings an algorithmic
      improvement.  Union of two `VarSet`s takes linear time the size of the
      sets and in the worst case we can have `n` unions of sets of sizes
      `(n-1, 1), (n-2, 1)...` making it quadratic.
      
      One reason why we need deterministic `tyVarsOfType` is in `abstractVars`
      in `SetLevels`. When we abstract type variables when floating we want
      them to be abstracted in deterministic order.
      
      Test Plan: harbormaster
      
      Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1468
      
      GHC Trac Issues: #4012
      2325bd4e
  17. 07 Nov, 2015 1 commit
  18. 06 Nov, 2015 1 commit
    • Joachim Breitner's avatar
      Call Arity: In "e x", the result of "x" is not shared · a58eeb7f
      Joachim Breitner authored
      in contrast to "e (f x)", where CorePrep will turn it into "let y = f x
      in e x". So in
        let f = ...
        in e (f x)
      we know that f is called at most once, but in
        let f = ...
        in e f
      we do not know that.
      
      Previously Call Arity would assume that in "e x", "x" is evaluated at
      most once. This rarely would make a difference (the argument "x" is
      analized with an incoming arity of 0, so no eta-expansion would be done
      anyways), but of course this should still be fixed.
      
      This fixes #11064.
      
      Note the corresponding code dmdTransformThunkDmd in DmdAnal.
      a58eeb7f
  19. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  20. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  21. 27 Oct, 2015 1 commit
  22. 17 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make Monad/Applicative instances MRP-friendly · e8ed2136
      Herbert Valerio Riedel authored
      This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
      such that the explicit definitions for `return` and `(>>)` match the
      MRP-style default-implementation, i.e.
      
        return = pure
      
      and
      
        (>>) = (*>)
      
      This way, e.g. all `return = pure` definitions can easily be grepped and
      removed in GHC 8.1;
      
      Test Plan: Harbormaster
      
      Reviewers: goldfire, alanz, bgamari, quchen, austin
      
      Reviewed By: quchen, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1312
      e8ed2136
  23. 13 Oct, 2015 1 commit
    • afarmer's avatar
      Don't inline/apply other rules when simplifying a rule RHS. · dcc34287
      afarmer authored
      HERMIT users depend on RULES to specify equational properties. 7.10.2
      performed both inlining and simplification in both sides of the rules, meaning
      they can't really be used for this. This breaks most HERMIT use cases.  A
      separate commit already disabled this for the LHS of rules. This does so for
      the RHS.
      
      See Trac #10829 for nofib results.
      
      Reviewed By: austin, bgamari, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1246
      
      GHC Trac Issues: #10829
      dcc34287
  24. 10 Oct, 2015 1 commit
  25. 06 Oct, 2015 1 commit
  26. 01 Oct, 2015 1 commit
  27. 26 Aug, 2015 1 commit
  28. 06 Aug, 2015 1 commit
  29. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Allow proper errors/warnings in core2core passes · e2b57381
      Simon Peyton Jones authored
      This patch makes it possible for core-to-core passes to emit
      proper error messages and warnings.
      
        * New function CoreMonad.warnMsg
      
        * CoreMonad.warnMsg and errorMsg now print a proper warning/error
          message heading.
      
        * CoreMonad carries a SrcSpan, which is used in warning/error
          messages.  It is initialised to be the source file name, but
          a core-to-core pass could set it more specifically if it had
          better location information.
      
      There was a bit of plumbing needed to get the filename to the
      right place.
      e2b57381
  30. 27 Jul, 2015 1 commit
  31. 16 Jul, 2015 1 commit
  32. 10 Jul, 2015 1 commit
  33. 20 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Filter orphan rules based on imports, fixes #10294 and #10420. · 0cb1f5cf
      Edward Z. Yang authored
      Summary:
      If we have an orphan rule in our database, don't apply it
      unless the defining module is transitively imported by the
      module we are processing.  We do this by defining a new RuleEnv
      data type which includes both the RuleBase as well as the set
      of visible orphan modules, and threading this through the
      relevant environments (CoreReader, RuleCheckEnv and ScEnv).
      
      This is analogous to the instances fix we applied in #2182
      4c834fdd, but done for RULES.
      An important knock-on effect is that we can remove some buggy
      code in LoadInterface which tried to avoid loading interfaces
      that were loaded by plugins (which sometimes caused instances
      and rules to NEVER become visible).
      
      One note about tests: I renamed the old plugins07 test to T10420
      and replaced plugins07 with a test to ensure that a plugin
      import did not cause new rules to be loaded in.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D950
      
      GHC Trac Issues: #10420
      0cb1f5cf
  34. 18 Jun, 2015 2 commits
    • Simon Peyton Jones's avatar
      Refactor filterAlts into two parts · ee643698
      Simon Peyton Jones authored
      This splits filterAlts into two:
       - filterAlts
       - refineDefaultAlt
      
      No change in functionality
      ee643698
    • Simon Peyton Jones's avatar
      Care with impossible-cons in combineIdenticalAlts · 023a0ba9
      Simon Peyton Jones authored
      This was a nasty, long-standing bug exposed in Trac #10538.
      Symptoms were that we had an empty case
         case (x :: Either a) of {}
      Core Lint correctly picked this bogus code up.
      
      Here is what happened
      
      * In SimplUtils.prepareAlts, we call
              filterAlts
        then
              combineIdenticalAlts
      
      * We had    case x of { Left _ -> e1; Right _ -> e1 }
      
      * filterAlts did nothing, but correctly retuned imposs_deflt_cons
        saying that 'x' cannot be {Left, Right} in the DEFAULT branch,
        if any (there isn't one.)
      
      * combineIdentialAlts correctly combines the identical alts, to give
           case x of { DEFAULT -> e1 }
      
      * BUT combineIdenticalAlts did no adjust imposs_deft_cons
      
      * Result: when compiling e1 we did so in the belief that 'x'
        could not be {Left,Right}.  Disaster.
      
      Easily fixed.
      
      (It is hard to trigger; I can't construct a simple test case.)
      023a0ba9
  35. 02 Jun, 2015 1 commit
    • Austin Seipp's avatar
      compiler: make sure we reject -O + HscInterpreted · 091944e3
      Austin Seipp authored
      When using GHCi, we explicitly reject optimization, because the
      compilers optimization passes can introduce unboxed tuples, which the
      interpreter is not able to handle. But this goes the other way too: using
      GHCi on optimized code may cause the optimizer to float out breakpoints
      that the interpreter introduces. This manifests itself in weird ways,
      particularly if you as an API client use custom DynFlags to introduce
      optimization in combination with HscInterpreted.
      
      It turns out we weren't checking for consistent DynFlag settings when
      doing `setSessionDynFlags`, as #10052 showed. While the main driver
      handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
      elsewhere.
      
      This does a little refactoring to split out some of the common code, and
      immunizes the various `DynFlags` utilities in the `GHC` module from this
      particular bug. We should probably be checking other general invariants
      too.
      
      This fixes #10052, and adds some notes about the behavior in `GHC` and
      `FloatOut`
      
      As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
      didn't exist (somehow).
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: edsko
      
      Differential Revision: https://phabricator.haskell.org/D727
      
      GHC Trac Issues: #10052
      091944e3
  36. 01 Jun, 2015 2 commits