GitLab

Eric Seidel authored Jan 18, 2016 and Ben Gamari committed Jan 18, 2016

I missed a crucial step in the wiring-in process of `CallStack` in D861,
the bit where you actually wire-in the Name... This led to a nasty bug
where GHC thought `CallStack` was not wired-in and tried to fingerprint
it, which failed because the defining module was not loaded.

But we don't need `CallStack` to be wired-in anymore since `error` and
`undefined` no longer need to be wired-in. So we just remove them all.

Updates haddock submodule.

Test Plan: `./validate` and `make slowtest TEST=tc198`

Reviewers: simonpj, goldfire, austin, hvr, bgamari

Reviewed By: simonpj, bgamari

Subscribers: goldfire, thomie

Projects: #ghc

Differential Revision: https://phabricator.haskell.org/D1739

GHC Trac Issues: #11331

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

Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and
GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP
compatibility CPP-mess for good!

Reviewers: austin, goldfire, bgamari

Subscribers: goldfire, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D1724

This re-working of the typechecker algorithm is based on
the paper "Visible type application", by Richard Eisenberg,
Stephanie Weirich, and Hamidhasan Ahmed, to be published at
ESOP'16.

This patch introduces -XTypeApplications, which allows users
to say, for example `id @Int`, which has type `Int -> Int`. See
the changes to the user manual for details.

This patch addresses tickets #10619, #5296, #10589.

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.

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.

Ryan Scott authored Dec 07, 2015 and Ben Gamari committed Dec 07, 2015

Test Plan: Validate.

Reviewers: simonpj, goldfire, hvr, dreixel, kosmikus, austin, bgamari

Reviewed By: kosmikus, austin, bgamari

Subscribers: RyanGlScott, Fuuzetsu, bgamari, thomie, carter, dreixel

Differential Revision: https://phabricator.haskell.org/D493

GHC Trac Issues: #9766

Simon Peyton Jones authored Dec 01, 2015 and Ben Gamari committed Dec 01, 2015

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.

Summary:
At the moment ghc-exactprint, which uses the GHC API Annotations to
provide a framework for roundtripping Haskell source code with optional
AST edits, has to implement a horrible workaround to manage the points
where layout needs to be captured.

These are

    MatchGroup
    HsDo
    HsCmdDo
    HsLet
    LetStmt
    HsCmdLet
    GRHSs

To provide a more natural representation, the contents subject to layout
rules need to be wrapped in a SrcSpan.

This commit does this.

Trac ticket #10250

Test Plan: ./validate

Reviewers: hvr, goldfire, bgamari, austin, mpickering

Reviewed By: mpickering

Subscribers: thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D1370

GHC Trac Issues: #10250

This implements DuplicateRecordFields, the first part of the
OverloadedRecordFields extension, as described at
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields

This includes fairly wide-ranging changes in order to allow multiple
records within the same module to use the same field names.  Note that
it does *not* allow record selector functions to be used if they are
ambiguous, and it does not have any form of type-based disambiguation
for selectors (but it does for updates). Subsequent parts will make
overloading selectors possible using orthogonal extensions, as
described on the wiki pages.  This part touches quite a lot of the
codebase, and requires changes to several GHC API datatypes in order
to distinguish between field labels (which may be overloaded) and
selector function names (which are always unique).

The Haddock submodule has been adapted to compile with the GHC API
changes, but it will need further work to properly support modules
that use the DuplicateRecordFields extension.

Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
will be extended once the other parts are implemented.

Reviewers: goldfire, bgamari, simonpj, austin

Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
goldfire

Differential Revision: https://phabricator.haskell.org/D761

Comes with Haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Ryan Scott authored Oct 03, 2015 and Ben Gamari committed Oct 03, 2015

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

Summary:
This implements -XDeriveLift, which allows for automatic derivation
of the Lift class from template-haskell. The implementation is based
off of Ian Lynagh's th-lift library
(http://hackage.haskell.org/package/th-lift).

Test Plan: ./validate

Reviewers: hvr, simonpj, bgamari, goldfire, austin

Reviewed By: goldfire, austin

Subscribers: osa1, thomie

Differential Revision: https://phabricator.haskell.org/D1168

GHC Trac Issues: #1830

The names of auxiliary bindings end up in the interface file, and since uniques
are nondeterministic, we end up with nondeterministic interface files.

This uses the package and module name in the generated name, so I believe it
should avoid problems from #7947 and be deterministic as well.

The generated names look like this now:

  `$cLrlbmVwI3gpI8G2E6Hg3mO`

and with `-ppr-debug`:

  `$c$aeson_70dylHtv1FFGeai1IoxcQr$Data.Aeson.Types.Internal$String`.

Reviewed By: simonmar, austin, ezyang

Differential Revision: https://phabricator.haskell.org/D1133

GHC Trac Issues: #4012

RyanGlScott authored Jul 17, 2015 and Ben Gamari committed Jul 17, 2015

Reviewers: dolio, shachaf, ekmett, austin, #core_libraries_committee,
simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie, bgamari

Differential Revision: https://phabricator.haskell.org/D1031

GHC Trac Issues: #10447

Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
    class (c1, c2) => (c2, c2)

This change was provoked by

  #10359  inability to re-use a given tuple
          constraint as a whole

  #9858   confusion between term tuples
          and constraint tuples

but it's generally a very nice simplification. We get rid of
 -  In Type, the TuplePred constructor of PredTree,
    and all the code that dealt with TuplePreds
 -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

See Note [How tuples work] in TysWiredIn.

Of course, nothing is ever entirely simple. This one
proved quite fiddly.

- I did quite a bit of renaming, which makes this patch
  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

- I made constraint tuples known-key rather than wired-in.
  This is different to boxed/unboxed tuples, but it proved
  awkward to have all the superclass selectors wired-in.
  Easier just to use the standard mechanims.

- While I was fiddling with known-key names, I split the TH Name
  definitions out of DsMeta into a new module THNames.  That meant
  that the known-key names can all be gathered in PrelInfo, without
  causing module loops.

- I found that the parser was parsing an import item like
      T( .. )
  as a *data constructor* T, and then using setRdrNameSpace to
  fix it.  Stupid!  So I changed the parser to parse a *type
  constructor* T, which means less use of setRdrNameSpace.

  I also improved setRdrNameSpace to behave better on Exact Names.
  Largely on priciple; I don't think it matters a lot.

- When compiling a data type declaration for a wired-in thing like
  tuples (,), or lists, we don't really need to look at the
  declaration.  We have the wired-in thing!  And not doing so avoids
  having to line up the uniques for data constructor workers etc.
  See Note [Declarations for wired-in things]

- I found that FunDeps.oclose wasn't taking superclasses into
  account; easily fixed.

- Some error message refactoring for invalid constraints in TcValidity

- Haddock needs to absorb the change too; so there is a submodule update

This reverts multiple commits from Simon:

  - 04a484ea Test Trac #10359
  - a9ccd37a Test Trac #10403
  - c0aae6f6 Test Trac #10248
  - eb6ca851 Make the "matchable-given" check happen first
  - ca173aa3 Add a case to checkValidTyCon
  - 51cbad15 Update haddock submodule
  - 6e1174da Separate transCloVarSet from fixVarSet
  - a8493e03 Fix imports in HscMain (stage2)
  - a154944b Two wibbles to fix the build
  - 5910a1bc Change in capitalisation of error msg
  - 130e93aa Refactor tuple constraints
  - 8da785d5 Delete commented-out line

These break the build by causing Haddock to fail mysteriously when
tr...

Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
    class (c1, c2) => (c2, c2)

This change was provoked by

  #10359  inability to re-use a given tuple
          constraint as a whole

  #9858   confusion between term tuples
          and constraint tuples

but it's generally a very nice simplification. We get rid of
 -  In Type, the TuplePred constructor of PredTree,
    and all the code that dealt with TuplePreds
 -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

See Note [How tuples work] in TysWiredIn.

Of course, nothing is ever entirely simple. This one
proved quite fiddly.

- I did quite a bit of renaming, which makes this patch
  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

- I made constraint tuples known-key rather than wired-in.
  This is different to boxed/unboxed tuples, but it proved
  awkward to have all the superclass selectors wired-in.
  Easier just to use the standard mechanims.

- While I was fiddling with known-key names, I split the TH Name
  definitions out of DsMeta into a new module THNames.  That meant
  that the known-key names can all be gathered in PrelInfo, without
  causing module loops.

- I found that the parser was parsing an import item like
      T( .. )
  as a *data constructor* T, and then using setRdrNameSpace to
  fix it.  Stupid!  So I changed the parser to parse a *type
  constructor* T, which means less use of setRdrNameSpace.

  I also improved setRdrNameSpace to behave better on Exact Names.
  Largely on priciple; I don't think it matters a lot.

- When compiling a data type declaration for a wired-in thing like
  tuples (,), or lists, we don't really need to look at the
  declaration.  We have the wired-in thing!  And not doing so avoids
  having to line up the uniques for data constructor workers etc.
  See Note [Declarations for wired-in things]

- I found that FunDeps.oclose wasn't taking superclasses into
  account; easily fixed.

- Some error message refactoring for invalid constraints in TcValidity

This reverts commit fb54b2c1.

As Alan pointed out, this will make cherry picking a lot harder until
7.10.2, so lets back it out until after the release.

At the moment ghc-exactprint, which uses the GHC API Annotations to
provide a framework for roundtripping Haskell source code with optional
AST edits, has to implement a horrible workaround to manage the points
where layout needs to be captured.

These are

    MatchGroup
    HsDo
    HsCmdDo
    HsLet
    LetStmt
    HsCmdLet
    GRHSs

To provide a more natural representation, the contents subject to layout
rules need to be wrapped in a SrcSpan.

This commit does this.

Trac ticket #10250

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D815

GHC Trac Issues: #10250

This makes TupleTyCon into an ordinary AlgTyCon, distinguished
by its AlgTyConRhs, rather than a separate constructor of TyCon.

It is preparatory work for making constraint tuples into classes,
for which the ConstraintTuple tuples will have a TyConParent
of a ClassTyCon.  Tuples didn't have this possiblity before.

The patch affects other modules because I eliminated the
unsatisfactory partial functions tupleTyConBoxity and tupleTyConSort.
And tupleTyConArity which is just tyConArity.

* don't call `nlHsPar`, as `genOpApp` already does so.
* don't reimplement `isUnboxedTupleTyCon` and `isBoxedTupleTyCon`.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D798

Parsing of static and mode flags happens before any session is started,
i.e., before the first call to 'GHC.withGhc'. Therefore, to report
errors for invalid usage of these two types of flags, we can not call
any function that needs DynFlags, as there are no DynFlags available yet
(unsafeGlobalDynFlags is not set either). So we always print "on the
commandline" as the location, which is true except for Api users, which
is probably ok.

When reporting errors for invalid usage of dynamic flags we /can/ make
use of DynFlags, and we do so explicitly in
DynFlags.parseDynamicFlagsFull.

Before, we called unsafeGlobalDynFlags when an invalid (combination of)
flag(s) was given on the commandline, resulting in panics (#9963). This
regression was introduced in 1d6124de.

Also rename showSDocSimple to showSDocUnsafe, to hopefully prevent this
from happening again.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D730

GHC Trac Issues: #9963

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

Whether to re-export the `<$>` non-method operator from `Prelude` wasn't
explicitly covered in the original AMP proposal[1], but it turns out that
not doing so forces most code that makes use of applicatives to import
`Data.Functor` or `Control.Applicative` just to get that operator into
scope.  To this end, it was proposed to add `<$>` to Prelude as well[2].

The down-side is that this increases the amount of redundant-import
warnings triggered, as well as the relatively minor issue of stealing
the `<$>` operator from the default namespace for good (although at this
point `<$>` is supposed to be ubiquitous anyway due to `Applicative`
being implicitly required into the next Haskell Report)

 [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
 [2]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161

Reviewed By: austin, ekmett

Differential Revision: https://phabricator.haskell.org/D680

Summary:
The 2010 report mentions:
"The result of `show` is a syntactically correct Haskell expression ...
Parenthesis are only added where needed, //ignoring associativity//".

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D669

GHC Trac Issues: #2530

Test Plan: deriving/should_run/T10104

Reviewers: austin, jstolarek

Reviewed By: austin, jstolarek

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D672

GHC Trac Issues: #10104

Signed-off-by: Austin Seipp <austin@well-typed.com>

The problem and its solution are explained in
   Note [Auxiliary binders]
in TcGenDeriv

If we have

   data family D a
   data instance D (a,b,c) = ... deriving( Data )

then we want to generate

   instance ... => Data (D (a,b,c)) where
     ...
     dataCast1 x = gcast1 x

The "1" here comes from the kind of D.  But the kind of the
*representation* TyCon is

   data Drep a b c = ....

ie Drep :: * -> * -> * -> *

So we must look for the *family* TyCon in this (rather horrible)
dataCast1 / dataCast2 binding.

Summary:
Add support for Partial Type Signatures, i.e. holes in types, see:
https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures

This requires an update to the Haddock submodule.

Test Plan: validate

Reviewers: austin, goldfire, simonpj

Reviewed By: simonpj

Subscribers: thomie, Iceland_jack, dominique.devriese, simonmar, carter, goldfire

Differential Revision: https://phabricator.haskell.org/D168

GHC Trac Issues: #9478

Summary:
Make HsLit and OverLitVal have original source strings, for source to
source conversions using the GHC API

This is part of the ongoing AST Annotations work, as captured in
https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations and
https://ghc.haskell.org/trac/ghc/ticket/9628#comment:28

The motivations for the literals is as follows

```lang=haskell
x,y :: Int
x = 0003
y = 0x04

s :: String
s = "\x20"

c :: Char
c = '\x20'

d :: Double
d = 0.00

blah = x
  where
    charH = '\x41'#
    intH = 0004#
    wordH = 005##
    floatH = 3.20#
    doubleH = 04.16##
    x = 1
```

Test Plan: ./sh validate

Reviewers: simonpj, austin

Reviewed By: simonpj, austin

Subscribers: thomie, goldfire, carter, simonmar

Differential Revision: https://phabricator.haskell.org/D412

GHC Trac Issues: #9628

This commit also refactors a bunch of lexeme-oriented code into
a new module Lexeme, and includes a submodule update for haddock.

Summary: (this has been submitted on behalf on @dreixel)

Reviewers: simonpj, hvr, austin

Reviewed By: simonpj, austin

Subscribers: goldfire, thomie, carter, dreixel

Differential Revision: https://phabricator.haskell.org/D476

GHC Trac Issues: #5462

mgmeier authored Oct 18, 2014 and Herbert Valerio Riedel committed Oct 18, 2014

This finally removes the `Data.OldTypeable` module (which
has been deprecated in 7.8), from `base`, compiler and testsuite.

The deprecated `Typeable{1..7}` aliases in `Data.Typeable` are not
removed yet in order to give existing code a bit more time to adapt.

Reviewed By: hvr, dreixel

Differential Revision: https://phabricator.haskell.org/D311