1. 14 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Make error when deriving an instance for a typeclass less misleading · d5a4e49d
      Ryan Scott authored
      Before, when you attempted to derive an instance for a typeclass,
      e.g.,
      
      ```
      class C1 (a :: Constraint) where
      class C2 where
      
      deriving instance C1 C2
      ```
      
      GHC would complain that `C2`'s data constructors aren't in scope. But
      that
      makes no sense, since typeclasses don't have constructors! By refining
      the
      checks that GHC performs when deriving, we can make the error message a
      little more sensible.
      
      This also cleans up a related `DeriveAnyClass` infelicity. Before, you
      wouldn't have been able to compile code like this:
      
      ```
      import System.IO (Handle)
      class C a
      deriving instance C Handle
      ```
      
      Since GHC was requiring that all data constructors of `Handle` be in
      scope. But `DeriveAnyClass` doesn't even generate code that mentions
      any data constructors, so this requirement is silly!
      
      Fixes #11509.
      
      Test Plan: make test TEST=T11509
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2558
      
      GHC Trac Issues: #11509
      d5a4e49d
  2. 06 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Refactor TcDeriv and TcGenDeriv · 4a03012a
      Ryan Scott authored
      Summary:
      Keeping a promise I made to Simon to clean up these modules.
      
      This change splits up the massive `TcDeriv` and `TcGenDeriv` modules into
      somewhat more manageable pieces. The new modules are:
      
      * `TcGenFunctor`: This contains the deriving machinery for `Functor`,
        `Foldable`, and `Traversable` (which all use the same underlying algorithm).
      * `TcDerivInfer`: This is the new home for `inferConstraints`,
        `simplifyInstanceContexts`, and related functions, whose role is to come up
        with the derived instance context and subsequently simplify it.
      * `TcDerivUtils`: This is a grab-bag module that contains several
        error-checking utilities originally in `TcDeriv`, as well as some functions
        that `TcDeriv` and `TcDerivInfer` both need.
      
      The end result is that `TcDeriv` is now less than 1,600 SLOC (originally 2,686
      SLOC), and `TcGenDeriv` is now about 2,000 SLOC (originally 2,964).
      
      In addition, this also implements a couple of tiny refactorings:
      
      * I transformed `type Condition = (DynFlags, TyCon) -> Validity` into
        `type Condition = DynFlags -> TyCon -> Validity`
      * I killed the `DerivSpecGeneric` constructor for `DerivSpecMechanism`, and
        merged its functionality into `DerivSpecStock`. In addition,
        `hasStockDeriving` now contains key-value pairs for `Generic` and `Generic1`,
        so they're no longer treated as an awkward special case in `TcDeriv`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2568
      4a03012a
  3. 05 Oct, 2016 1 commit
  4. 02 Oct, 2016 1 commit
  5. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765
  6. 30 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      b612da66
  7. 15 Sep, 2016 1 commit
    • Ben Gamari's avatar
      Unify CallStack handling in ghc · 626db8f8
      Ben Gamari authored
      Here we introduce compatibility wrappers for HasCallStack constraints.
      This is necessary as we must support GHC 7.10.1 which lacks sane call
      stack support. We also introduce another constraint synonym,
      HasDebugCallStack, which only provides a call stack when DEBUG is set.
      626db8f8
  8. 05 Sep, 2016 1 commit
  9. 29 Aug, 2016 1 commit
    • Ryan Scott's avatar
      Remove unused DerivInst constructor for DerivStuff · f4384ef5
      Ryan Scott authored
      Summary:
      Back when derived `Generic` instances used to generate auxiliary datatypes,
      they would also generate instances for those datatypes. Nowadays, GHC generics
      uses a `DataKinds`-based encoding that requires neither auxiliary datatypes
      (corresponding to the `DerivTyCon` constructor of `DerivStuff`) nor instances
      for them (the `DerivInst` constructor of `DerivStuff`). It appears that
      `DerivTyCon` constructor was removed at some point, but `DerivInst` never was.
      
      No `DerivInst` values are ever constructed, so we can safely remove it.
      
      Test Plan: It builds
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2481
      f4384ef5
  10. 05 Jul, 2016 1 commit
    • Simon Peyton Jones's avatar
      Make unique auxiliary function names in deriving · 895eefa8
      Simon Peyton Jones authored
      In deriving for Data, we make some auxiliary functions, but they
      didn't always get distinct names (Trac #12245).  This patch fixes
      it by using the same mechanism as for dictionary functions, namely
      chooseUniqueOccTc.
      
      Some assocated refactoring came along for the ride.
      895eefa8
  11. 23 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Give lookupGRE_Name a better API · 3e0af469
      Simon Peyton Jones authored
      lookupGRE_Name should return either zero or one GREs, never
      several. This is a consequence of INVARIANT 1 on GlobalRdrEnv.
      
      So it's better if it returns a Maybe; the panic on multiple results
      is put in one place, instead of being scattered or ignored.
      
      Just refactoring, no change in behaviour
      3e0af469
  12. 22 Jun, 2016 1 commit
  13. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
      
        - tyConBinders :: [TyConBinder]
      
      The new data types look like this:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
      
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
      
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      
      Some smaller points
      ~~~~~~~~~~~~~~~~~~~
      * Nice new functions
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
      e368f326
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  14. 14 Jun, 2016 1 commit
    • niteria's avatar
      Rename cmpType to nonDetCmpType · 9d22fbe2
      niteria authored
      This makes it obvious that it's nondeterministic and hopefully
      will prevent someone from using it accidentally.
      
      GHC Trac: #4012
      9d22fbe2
  15. 24 May, 2016 1 commit
    • Ryan Scott's avatar
      Remove 'deriving Typeable' statements · 95dfdceb
      Ryan Scott authored
      Summary:
      Deriving `Typeable` has been a no-op since GHC 7.10, and now that we
      require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable`
      statements in GHC.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, hvr, bgamari
      
      Reviewed By: austin, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2260
      95dfdceb
  16. 12 May, 2016 2 commits
    • Ryan Scott's avatar
      Make Generic1 poly-kinded · b8e25651
      Ryan Scott authored
      This generalizes the `Generic1` typeclass to be of kind `k -> *`, and
      this also makes the relevant datatypes and typeclasses in `GHC.Generics`
      poly-kinded. If `PolyKinds` is enabled, `DeriveGeneric` derives
      `Generic1` instances such that they use the most general kind possible.
      Otherwise, deriving `Generic1` defaults to make an instance where the
      argument is of kind `* -> *` (the current behavior).
      
      Fixes #10604. Depends on D2117.
      
      Test Plan: ./validate
      
      Reviewers: kosmikus, dreixel, goldfire, austin, hvr, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie, ekmett
      
      Differential Revision: https://phabricator.haskell.org/D2168
      
      GHC Trac Issues: #10604
      b8e25651
    • Ryan Scott's avatar
      Fix deriveTyData's kind unification when two kind variables are unified · e53f2180
      Ryan Scott authored
      When `deriveTyData` attempts to unify two kind variables (which can
      happen if both the typeclass and the datatype are poly-kinded), it
      mistakenly adds an extra mapping to its substitution which causes the
      unification to fail when applying the substitution. This can be
      prevented by checking both the domain and the range of the original
      substitution to see which kind variables shouldn't be put into the
      domain of the substitution. A more in-depth explanation is included in
      `Note [Unification of two kind variables in deriving]`.
      
      Fixes #11837.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, hvr, goldfire, niteria, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2117
      
      GHC Trac Issues: #11837
      e53f2180
  17. 10 May, 2016 2 commits
  18. 30 Apr, 2016 1 commit
  19. 20 Apr, 2016 3 commits
    • niteria's avatar
      Rename FV related functions · 2e33320a
      niteria authored
      This is from Simon's suggestion:
      
      * `tyCoVarsOfTypesAcc` is a terrible name for a function with a
        perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`?
        Similarly others
      
      * `runFVList` is also terrible, but also has a decent type.
        Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`).
      
      * `someVars` could be `mkFVs :: [Var] -> FV`.
      2e33320a
    • niteria's avatar
      Kill unnecessary varSetElemsWellScoped in deriveTyData · 687c7780
      niteria authored
      varSetElemsWellScoped introduces unnecessary non-determinism and it's possible
      to do the same thing deterministically for the same price.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonmar, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2124
      
      GHC Trac Issues: #4012
      687c7780
    • Simon Peyton Jones's avatar
      SCC analysis for instances as well as types/classes · 353d8ae6
      Simon Peyton Jones authored
      This big patch is in pursuit of Trac #11348.
      
      It is largely the work of Alex Veith (thank you!), with some
      follow-up simplification and refactoring from Simon PJ.
      
      The main payload is described in RnSource
        Note [Dependency analysis of type, class, and instance decls]
      which is pretty detailed.
      
      * There is a new data type HsDecls.TyClGroup, for a strongly
        connected component of type/class/instance/role decls.
      
        The hs_instds field of HsGroup disappears, in consequence
      
        This forces some knock-on changes, including a minor
        haddock submodule update
      
      Smaller, weakly-related things
      
      * I found that both the renamer and typechecker were building an
        identical env for RoleAnnots, so I put common code for
        RoleAnnotEnv in RnEnv.
      
      * I found that tcInstDecls1 had very clumsy error handling, so I
        put it together into TcInstDcls.doClsInstErrorChecks
      353d8ae6
  20. 19 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Tighten checking for associated type instances · 8136a5cb
      Simon Peyton Jones authored
      This patch finishes off Trac #11450.  Following debate on that ticket,
      the patch tightens up the rules for what the instances of an
      associated type can look like.  Now they must match the instance
      header exactly. Eg
      
         class C a b where
          type T a x b
      
      With this class decl, if we have an instance decl
        instance C ty1 ty2 where ...
      then the type instance must look like
           type T ty1 v ty2 = ...
      with exactly
        - 'ty1' for 'a'
        -  'ty2' for 'b', and
        - a variable for 'x'
      
      For example:
      
        instance C [p] Int
          type T [p] y Int = (p,y,y)
      
      Previously we allowed multiple instance equations and now, in effect,
      we don't since they would all overlap.  If you want multiple cases,
      use an auxiliary type family.
      
      This is consistent with the treatment of generic-default instances,
      and the user manual always said "WARNING: this facility (multiple
      instance equations may be withdrawn in the future".
      
      I also improved error messages, and did other minor refactoring.
      8136a5cb
  21. 15 Apr, 2016 1 commit
    • niteria's avatar
      Remove some gratitious varSetElemsWellScoped · 31e49746
      niteria authored
      Summary:
      `varSetElemsWellScoped` uses `varSetElems` under the hood which
      introduces unnecessary nondeterminism.
      This does the same thing, possibly cheaper, while preserving
      determinism.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, RyanGlScott
      
      Differential Revision: https://phabricator.haskell.org/D2116
      
      GHC Trac Issues: #4012
      31e49746
  22. 14 Apr, 2016 1 commit
  23. 11 Apr, 2016 1 commit
    • Ryan Scott's avatar
      Deriving Functor-like classes should unify kind variables · aadde2b9
      Ryan Scott authored
      While the deriving machinery always unifies the kind of the typeclass
      argument with the kind of the datatype, this proves not to be sufficient
      to produce well kinded instances for some poly-kinded datatypes. For
      example:
      
      ```
      newtype Compose (f :: k2 -> *) (g :: k1 -> k2) (a :: k1)
        = Compose (f (g a)) deriving Functor
      ```
      
      would fail because only `k1` would get unified with `*`, causing the
      following
      ill kinded instance to be generated:
      
      ```
      instance (Functor (f :: k2 -> *), Functor (g :: * -> k2)) =>
        Functor (Compose f g) where ...
      ```
      
      To prevent this, we need to take the subtypes and unify their kinds with
      `* -> *`.
      
      Fixes #10524 for good.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, hvr, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2097
      
      GHC Trac Issues: #10524, #10561
      aadde2b9
  24. 10 Apr, 2016 1 commit
    • Ryan Scott's avatar
      Remove the instantiation check when deriving Generic(1) · 7443e5c8
      Ryan Scott authored
      Previously, deriving `Generic(1)` bailed out when attempting to
      instantiate visible type parameters (#5939), but this instantiation
      check was quite fragile and doesn't interact well with `-XTypeInType`.
      It has been decided that `Generic(1)` shouldn't be subjected to this
      check anyway, so it has been removed, and `gen_Generic_binds`'s
      machinery has been updated to substitute the type variables in a
      generated `Rep`/`Rep1` instance with the user-supplied type arguments.
      
      In addition, this also refactors `Condition` in `TcDeriv` a bit. Namely,
      since we no longer need `tc_args` to check any conditions, the `[Type]`
      component of `Condition` has been removed.
      
      Fixes #11732.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, kosmikus, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2061
      
      GHC Trac Issues: #5939, #11732
      7443e5c8
  25. 15 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11357. · 1eefedf7
      eir@cis.upenn.edu authored
      We were looking at a data instance tycon for visibility info,
      which is the wrong place to look. Look at the data family tycon
      instead.
      
      Also improved the pretty-printing near there to suppress kind
      arguments when appropriate.
      1eefedf7
  26. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  27. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  28. 17 Feb, 2016 1 commit
  29. 08 Feb, 2016 2 commits
  30. 27 Jan, 2016 2 commits
    • niteria's avatar
      Rename "open" subst functions · 5dcae88b
      niteria authored
      This is the renaming that @simonpj requested:
      ```
      · zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)
      
      · zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with
      covars)
      
      · zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals
      with TyBinders, not covars)
      ```
      plus the `mk` variant.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1853
      
      GHC Trac Issues: #11371
      5dcae88b
    • Ömer Sinan Ağacan's avatar
      s/unLifted/unlifted for consistency · 4faa1a63
      Ömer Sinan Ağacan authored
      This was causing trouble as we had to remember when to use "unLifted"
      and when to use "unlifted".
      
      "unlifted" is used instead of "unLifted" as it's a single word.
      
      Reviewers: austin, hvr, goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1852
      4faa1a63
  31. 26 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Kill off zipTopTCvSubst in favour of zipOpenTCvSubst · 1c6d70c2
      Simon Peyton Jones authored
      As Bartosz has discovered, the invariants for substitutions were
      wrong, and in particular the "mkTop...Subst" and "zipTop..Subst"
      functions were building substitutions that didn't obey even the
      old invariants.
      
      This patch kills of the bogus zipTopTCvSubst in favour of the
      more robust zipOpenTCvSubst.
      
      I tripped over this because my upcoming patch (concerning SetLevels,
      Trac #11330) triggered an ASSERT failure in the substitution
      well-formedness assertion in TyCoRep.
      1c6d70c2
  32. 18 Jan, 2016 2 commits
    • 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
    • Simon Peyton Jones's avatar
      White space only · b7e5c302
      Simon Peyton Jones authored
      b7e5c302