1. 17 Feb, 2016 1 commit
  2. 08 Feb, 2016 2 commits
  3. 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
  4. 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
  5. 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
  6. 15 Jan, 2016 2 commits
    • Ryan Scott's avatar
      Expand type/kind synonyms in TyVars before deriving-related typechecking · 165ae440
      Ryan Scott authored
      Before, it was possible to have a datatypes such as
      
      ```
      type ConstantT a b = a
      newtype T (f :: * -> *) (a :: ConstantT * f) = T (f a) deriving Functor
      
      data family TFam (f :: * -> *) (a :: *)
      newtype instance TFam f (ConstantT a f) = TFam (f a) deriving Functor
      ```
      
      fail to eta-reduce because either (1) a TyVar had a kind synonym that
      mentioned another TyVar, or (2) an instantiated type was itself a type
      synonym that mentioned another TyVar. A little bit of tweaking to
      `expandTypeSynonyms` and applying it before the eta-reduction check in
      the `deriving` machinery is sufficient to fix this.
      
      Fixes #11416.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1772
      
      GHC Trac Issues: #11416
      165ae440
    • Ryan Scott's avatar
      Refactor lookupFixityRn-related code following D1744 · 756b2283
      Ryan Scott authored
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1766
      
      GHC Trac Issues: #11345
      756b2283
  7. 07 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Use an Implication in 'deriving' error · 02c1c573
      Simon Peyton Jones authored
      Trac #11437 showed that erroneous constraints from a 'deriving'
      clause need to be wrapped in an Implication to properly scope
      their skolems.
      
      The main change is in TcDeriv.simplifyDeriv; the call to
      buildImplicationFor is new.
      02c1c573
  8. 16 Dec, 2015 1 commit
    • quchen's avatar
      Add `-W(no-)xxx` aliases for `-f(no-)warn-xxx` flags · 2206fa8c
      quchen authored
      This also updates the user's guide to refer to the `-W`-based warning
      flags by default.
      
      Quoting the release note entry:
      
      | Warnings can now be controlled with `-W(no-)...` flags in addition to
      | the old `-f(no-)warn...` ones. This was done as the first part of a
      | rewrite of the warning system to provide better control over warnings,
      | better warning messages, and more common syntax compared to other
      | compilers. The old `-fwarn...`-based warning flags will remain
      | functional for the forseeable future.
      
      This is part of
      https://ghc.haskell.org/wiki/Design/Warnings
      and addresses #11218
      
      Reviewed By: hvr, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1613
      2206fa8c
  9. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
  10. 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
  11. 09 Dec, 2015 2 commits
    • Gabor Greif's avatar
      More typos in comments/docs · 688069ca
      Gabor Greif authored
      688069ca
    • Simon Peyton Jones's avatar
      Fix DeriveAnyClass (Trac #9968) · af77089b
      Simon Peyton Jones authored
      The main issue concerned things like
      
         data T a = MkT a deriving( C Int )
      
      which is supposed to generate
      
         instance C Int (T a) where {}
      
      But the 'Int' argument (called cls_tys in the code) wasn't
      even being passed to inferConstraints and mk_data_eqn, so it
      really had no chance.   DeriveAnyClass came along after this
      code was written!
      
      Anyway I did quite a bit of tidying up in inferConstraints.
      
      Also I discovered that this case was not covered at all
      
         data T a b = MkT a b deriving( Bifunctor )
      
      What constraints should we generate for the instance context?
      We can deal with classes whose last arg has kind *, like Eq, Ord;
      or (* -> *), like Functor, Traversable.  But we really don't have
      a story for classes whose last arg has kind (* -> * -> *).
      
      So I augmented checkSideConditions to check for that and give
      a sensible error message.
      
      ToDo: update the user manual.
      af77089b
  12. 07 Dec, 2015 1 commit
  13. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
      
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
      
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
      
        HsExplicitFlag disappears altogether.
      
      * Other simplifications
      
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
      
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
      
           - PatSynSig records a LHsSigType rather than the decomposed
             pieces
      
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      
      * Renamed LHsTyVarBndrs to LHsQTyVars
      
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      
      I also did a bunch of loosely-related changes:
      
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
      
            TcCoercionN/TcCoercionR
      
            mkWpCastN/mkWpCastN
      
        All just type synonyms but jolly useful.
      
      * I record-ised ForeignImport and ForeignExport
      
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      
      Updates haddock submodule.
      1e041b73
  14. 25 Nov, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor default methods (Trac #11105) · 924f8517
      Simon Peyton Jones authored
      This patch does some signficant refactoring to the treatment
      of default methods in class declarations, and more generally
      to the type checking of type/class decls.
      
      Highlights:
      
      * When the class has a generic-default method, such as
           class C a where
             op :: a -> a -> Bool
             default op :: Ord a => a -> a -> a
        the ClassOpItem records the type of the generic-default,
        in this case the type (Ord a => a -> a -> a)
      
      * I killed off Class.DefMeth in favour of the very-similar
        BasicTypes.DefMethSpec.  However it turned out to be better
        to use a Maybe, thus
            Maybe (DefMethSpec Type)
        with Nothing meaning "no default method".
      
      * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing],
        but I found a way to make it much simpler, accumulating only
        a [TyCon].  Much less wrapping and unwrapping.
      
      * On the way I also fixed Trac #10896 in a better way. Instead
        of killing off all ambiguity checks whenever there are any type
        errors (the fix in commit 8e8b9ed9), I instead recover in
        TcTyClsDecls.checkValidTyCl.
      
      There was a lot of associated simplification all round
      924f8517
  15. 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
  16. 11 Nov, 2015 1 commit
  17. 30 Oct, 2015 1 commit
    • Simon Peyton Jones's avatar
      Record usage information using GlobalRdrElt · 3e94842d
      Simon Peyton Jones authored
      This patch implements an improvment that I've wanted to do for ages, but
      never gotten around to.
      
      Unused imports are computed based on how imported entities occur (qualified,
      unqualified).   This info was accumulated in tcg_used_rdrnames :: Set RdrName.
      But that was a huge pain, and it got worse when we introduced duplicate
      record fields.
      
      The Right Thing is to record tcg_used_gres :: [GlobalRdrElt], which records
      the GRE *after* filtering with pickGREs.  See Note [GRE filtering] in RdrName.
      This is much, much bette.  This patch deletes quite a bit of code, and is
      conceptually much easier to follow.
      
      Hooray.  There should be no change in functionality.
      3e94842d
  18. 03 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Fill in associated type defaults with DeriveAnyClass · 2f74be9c
      Ryan Scott authored
      Summary:
      Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in
      associated type family defaults when deriving a class which contained
      them.
      
      In order to fix this properly, `tcATDefault` needed to be used from
      `TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved
      from `TcInstDcls` to `TcClsDcl`.
      
      Fixes #10361.
      
      Test Plan: ./validate
      
      Reviewers: kosmikus, dreixel, bgamari, austin, simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1283
      
      GHC Trac Issues: #10361
      2f74be9c
  19. 24 Sep, 2015 1 commit
    • Ömer Sinan Ağacan's avatar
      Fix DeriveGeneric for types with same OccName (#10487) · b08a533d
      Ömer Sinan Ağacan authored
      Summary:
      DeriveGeneric generates some data types (for data type constructors and for
      selectors of those constructors) and instances for those types. This patch
      changes name generation for these new types to make it working with data types
      with same names imported from different modules and with data types with same
      names imported from same modules(using module imports).
      
      Bonus content:
      
      - Some refactoring in `TcGenGenerics.metaTyConsToDerivStuff` to remove some
        redundant partial function applications and to remove a duplicated function.
      - Remove some unused names from `OccName`. (those were used for an old
        implementation of `DeriveGeneric`)
      
      Reviewers: kosmikus, simonpj, dreixel, ezyang, bgamari, austin
      
      Reviewed By: bgamari, austin
      
      Subscribers: ezyang, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1081
      
      GHC Trac Issues: #10487
      b08a533d
  20. 22 Sep, 2015 1 commit
  21. 21 Sep, 2015 1 commit
  22. 19 Sep, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #10815 by kind-checking type patterns against known kinds. · 2d4db40a
      eir@cis.upenn.edu authored
      tcFamTyPats now must take information about the instantiation of any
      class variables, when checking the instance of an associated type.
      
      Getting this to work out required some unexpected refactoring in
      TcDeriv. TcDeriv needs to look at class instances because of the
      possibility of associated datatypes with `deriving` specs. TcDeriv
      worked over the user-specified instances. But any data family instances
      were already processed, and TcDeriv had no way of finding the rep
      tycons. Indeed, TcDeriv *re-type-checked* any data family instances
      in an attempt to rediscover what GHC already knew. So, this commit
      introduces better tracking of compiled data families between TcInstDcls
      and TcDeriv to streamline all of this.
      2d4db40a
  23. 26 Aug, 2015 1 commit
  24. 30 Jul, 2015 2 commits
    • JohnWiegley's avatar
      Improve error message for newtypes and deriving clauses · 4f80ec0e
      JohnWiegley authored
      Summary:
      Change the error message generated when a deriving clause related to a newtype
      fails to always suggested trying GeneralizedNewtypeDeriving, even in
      situations where it may not work. Fixes #9600.
      
      Test Plan: testsuite/deriving/should_fail/9600.hs
      
      Reviewers: austin, bgamari, simonpj
      
      Rebased-by: bgamari
      
      Reviewed By: simonpj
      
      Subscribers: bgamari, hvr, simonmar, carter
      
      Differential Revision: https://phabricator.haskell.org/D216
      
      GHC Trac Issues: #9600
      4f80ec0e
    • Simon Peyton Jones's avatar
      Better treatment of signatures in cls/inst · 72d23c3e
      Simon Peyton Jones authored
      The provoking cause for this patch is Trac #5001, comment:23.  There
      was an INLINE pragma in an instance decl, that shouldn't be there.
      But there was no complaint, just a  mysterious WARN later.
      
      I ended up having to do some real refactoring but the result is,
      I think, simpler and more robust.
      72d23c3e
  25. 16 Jul, 2015 1 commit
  26. 07 Jul, 2015 1 commit
  27. 26 Jun, 2015 1 commit
  28. 25 Jun, 2015 1 commit
  29. 03 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor RdrName.Provenance, to fix #7672 · 7ea156ae
      Simon Peyton Jones authored
      Trac #7672 has a data type T in module A that is in scope
      *both* locally-bound *and* imported (with a qualified) name.
      The Provenance of a GlobalRdrElt simply couldn't express that
      before. Now you can.
      
      In doing so, I flattened out Provenance into GlobalRdrElt,
      so quite a lot of modules are touched in a not-very-interesting
      way.
      7ea156ae
  30. 01 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Treat pattern-synonym binders more consistently · 11d8f84f
      Simon Peyton Jones authored
      Pattern-synonyms are in value declarations, but were being
      bound by getLocalNonValBinders.  This seemed odd, and indeed
      staightening it out allowed me to remove a field from
      TopSigCtxt.
      
      The main changes are in RnSource.rnSrcDecls.
      
      Nice.
      11d8f84f
  31. 29 Apr, 2015 1 commit
    • Simon Peyton Jones's avatar
      Improve improvement in the constraint solver · a1275a76
      Simon Peyton Jones authored
      This regrettably-big patch substantially improves the way in which
      "improvement" happens in the constraint solver.  It was triggered by
      trying to crack Trac #10009, but it turned out to solve #10340 as
      well.
      
      The big picture, with several of the trickiest examples, is described
      in Note [The improvement story] in TcInteract.
      
      The major change is this:
      
      * After solving we explicitly try "improvement", by
           - making the unsolved Wanteds into Deriveds
           - allowing Deriveds to rewrite Deriveds
        This more aggressive rewriting "unlocks" some extra
        guess-free unifications.
      
      * The main loop is in TcInteract.solveSimpleWanteds, but I also ended
        up refactoring TcSimplify.simpl_loop, and its surrounding code.
      
        Notably, any insolubles from the Givens are pulled out
        and treated separately, rather than staying in the inert set
        during the solveSimpleWanteds loop.
      
      There are a lot of follow-on changes
      
      * Do not emit generate Derived improvements from Wanteds.
        This saves work in the common case where they aren't needed.
      
      * For improvement we should really do type-class reduction on Derived
        constraints in doTopReactDict.  That entailed changing the GenInst
        constructor a bit; a local and minor change
      
      * Some annoying faffing about with dropping derived constraints;
        see dropDerivedWC, dropDerivedSimples, dropDerivedInsols,
        and their Notes.
      
      * Some substantial refactoring in TcErrors.reportWanteds.
        This work wasn't strictly forced, but I got sucked into it.
        All the changes are in TcErrors.
      
      * Use TcS.unifyTyVar consistently, rather than setWantedTyBind,
        so that unifications are properly tracked.
      
      * Refactoring around solveWantedsTcM, solveWantedsAndDrop.
        They previously guaranteed a zonked result, but it's more
        straightforward for clients to zonk.
      a1275a76
  32. 10 Apr, 2015 1 commit
  33. 07 Mar, 2015 1 commit
    • Iavor S. Diatchki's avatar
      Custom `Typeable` solver, that keeps track of kinds. · b359c886
      Iavor S. Diatchki authored
      Summary:
      This implements the new `Typeable` solver: when GHC sees `Typeable` constraints
      it solves them on the spot.
      
      The current implementation creates `TyCon` representations on the spot.
      
      Pro: No overhead at all in code that does not use `Typeable`
      Cons: Code that uses `Typeable` may create multipe `TyCon` represntations.
      
      We have discussed an implementation where representations of `TyCons` are
      computed once, in the module, where a datatype is declared.  This would
      lead to more code being generated:  for a promotable datatype we need to
      generate `2 + number_of_data_cons` type-constructro representations,
      and we have to do that for all programs, even ones that do not intend to
      use typeable.
      
      I added code to emit warning whenevar `deriving Typeable` is encountered---
      the idea being that this is not needed anymore, and shold be fixed.
      
      Also, we allow `instance Typeable T` in .hs-boot files, but they result
      in a warning, and are ignored.  This last one was to avoid breaking exisitng
      code, and should become an error, eventually.
      
      Test Plan:
      1. GHC can compile itself.
      2. I compiled a number of large libraries, including `lens`.
          - I had to make some small changes:
            `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix
          - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance
      
      3. I also run some code that uses `syb` to traverse a largish datastrucutre.
      I didn't notice any signifiant performance difference between the 7.8.3 version,
      and this implementation.
      
      Reviewers: simonpj, simonmar, austin, hvr
      
      Reviewed By: austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D652
      
      GHC Trac Issues: #9858
      b359c886
  34. 02 Mar, 2015 1 commit