GitLab

Sylvain Henry authored Nov 22, 2018 and Ben Gamari committed Nov 22, 2018

In a previous patch we replaced some built-in literal constructors
(MachInt, MachWord, etc.) with a single LitNumber constructor.

In this patch we replace the `Mach` prefix of the remaining constructors
with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).

Sadly the name `LitString` was already taken for a kind of FastString
and it would become misleading to have both `LitStr` (literal
constructor renamed after `MachStr`) and `LitString` (FastString
variant). Hence this patch renames the FastString variant `PtrString`
(which is more accurate) and the literal string constructor now uses the
least surprising `LitString` name.

Both `Literal` and `LitString/PtrString` have recently seen breaking
changes so doing this kind of renaming now shouldn't harm much.

Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers

Subscribers: tdammers, rwbarton, thomie, carter

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

Michal Terepeta authored Nov 02, 2018 and Ben Gamari committed Nov 02, 2018

This is the first step of implementing:
https://github.com/ghc-proposals/ghc-proposals/pull/74



The main highlights/changes:

    primops.txt.pp gets two new sections for two new primitive types for
    signed and unsigned 8-bit integers (Int8# and Word8 respectively) along
    with basic arithmetic and comparison operations. PrimRep/RuntimeRep get
    two new constructors for them. All of the primops translate into the
    existing MachOPs.

    For CmmCalls the codegen will now zero-extend the values at call
    site (so that they can be moved to the right register) and then truncate
    them back their original width.

    x86 native codegen needed some updates, since it wasn't able to deal
    with the new widths, but all the changes are quite localized. LLVM
    backend seems to just work.

This is the second attempt at merging this, after the first attempt in
D4475 had to be backed out due to regressions on i386.

Bumps binary submodule.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate (on both x86-{32,64})

Reviewers: bgamari, hvr, goldfire, simonmar

Subscribers: rwbarton, carter

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

Sebastian Graf authored Oct 14, 2018 and Krzysztof Gogolewski committed Oct 14, 2018

Summary:
Trac #9279 reminded us that the worker wrapper transformation copes
really badly with absent unlifted boxed bindings.

As `Note [Absent errors]` in WwLib.hs points out, we can't just use
`absentError` for unlifted bindings because there is no bottom to hide
the error in.
So instead, we synthesise a new `RubbishLit` of type
`forall (a :: TYPE 'UnliftedRep). a`, which code-gen may subsitute for
any boxed value. We choose `()`, so that there is a good chance that
the program crashes instead instead of leading to corrupt data, should
absence analysis have been too optimistic (#11126).

Reviewers: simonpj, hvr, goldfire, bgamari, simonmar

Reviewed By: simonpj

Subscribers: osa1, rwbarton, carter

GHC Trac Issues: #15627, #9279, #4306, #11126

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

This unfortunately broke i386 support since it introduced references to
byte-sized registers that don't exist on that architecture.

Reverts binary submodule

This reverts commit 5d5307f9.

Michal Terepeta authored Oct 04, 2018 and Ben Gamari committed Oct 07, 2018

This is the first step of implementing:
https://github.com/ghc-proposals/ghc-proposals/pull/74



The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Bumps binary submodule.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter

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

Sylvain Henry authored Jun 15, 2018 and Ben Gamari committed Jun 15, 2018

Add support for built-in Natural literals in Core.

- Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
  constructor with a LitNumType field
- Support built-in Natural literals
- Add desugar warning for negative literals
- Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
  reasons

This patch introduces only a few rules for Natural literals (compared
to Integer's rules). Factorization of the built-in rules for numeric
literals will be done in another patch as this one is already big to
review.

Test Plan:
  validate
  test build with integer-simple

Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar

Reviewed By: bgamari

Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
thomie

GHC Trac Issues: #14170, #14465

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

Simon Marlow authored Mar 05, 2018 and Ben Gamari committed Mar 06, 2018

This was broken by D3746 and/or D3809, but unfortunately we didn't
notice because CI at the time wasn't building the profiling way.

Test Plan:
```
cd testsuite/test/profiling/should_run
make WAY=ghci-ext-prof
```

Reviewers: bgamari, michalt, hvr, erikd

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14705

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

This reverts f5b275a2
and changes the places that looked for `Lit (MachStr _))`
to use `exprIsMbTickedLitString_maybe` to unwrap ticks as
necessary.
Also updated relevant comments.

Test Plan:
I added 3 new tests that previously reproduced.
GHC HEAD now builds with -g

Reviewers: simonpj, simonmar, bgamari, hvr, goldfire

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14779

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

Ryan Scott authored Jan 02, 2018 and Ben Gamari committed Jan 02, 2018

Commit 714bebff removed
a check in the bytecode compiler that caught illegal uses of unboxed
tuples (and now sums) in case alternatives, which causes the program
in #14608 to panic. This restores the check (using modern,
levity-polymorphic vocabulary).

Test Plan: make test TEST=T14608

Reviewers: hvr, bgamari, dfeuer, simonpj

Reviewed By: dfeuer, simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14608

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

Michal Terepeta authored Oct 29, 2017 and Ben Gamari committed Oct 29, 2017

This is another step for fixing #13825

 and is based on D38 by Simon
Marlow.

The change allows storing multiple constructor fields within the same
word. This currently applies only to `Float`s, e.g.,
```
data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Float
```
on 64-bit arch, will now store both fields within the same constructor
word. For `WordX/IntX` we'll need to introduce new primop types.

Main changes:

- We now use sizes in bytes when we compute the offsets for
  constructor fields in `StgCmmLayout` and introduce padding if
  necessary (word-sized fields are still word-aligned)

- `ByteCodeGen` had to be updated to correctly construct the data
  types. This required some new bytecode instructions to allow pushing
  things that are not full words onto the stack (and updating
  `Interpreter.c`). Note that we only use the packed stuff when
  constructing data types (i.e., for `PACK`), in all other cases the
  behavior should not change.

- `RtClosureInspect` was changed to handle the new layout when
  extracting subterms. This seems to be used by things like `:print`.
  I've also added a test for this.

- I deviated slightly from Simon's approach and use `PrimRep` instead
  of `ArgRep` for computing the size of fields.  This seemed more
  natural and in the future we'll probably want to introduce new
  primitive types (e.g., `Int8#`) and `PrimRep` seems like a better
  place to do that (where we already have `Int64Rep` for example).
  `ArgRep` on the other hand seems to be more focused on calling
  functions.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar, austin, hvr, goldfire, erikd

Reviewed By: bgamari

Subscribers: maoe, rwbarton, thomie

GHC Trac Issues: #13825

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

Herbert Valerio Riedel authored Sep 19, 2017 and Ben Gamari committed Sep 19, 2017

This switches the compiler/ component to get compiled with
-XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
modules.

This is motivated by the upcoming "Prelude" re-export of
`Semigroup((<>))` which would cause lots of name clashes in every
modulewhich imports also `Outputable`

Reviewers: austin, goldfire, bgamari, alanz, simonmar

Reviewed By: bgamari

Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari

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

Ryan Scott authored Aug 01, 2017 and Ben Gamari committed Aug 01, 2017

GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
8.0. This means we can delete gobs of code that was only used for GHC
7.10 support. Hooray!

Test Plan: ./validate

Reviewers: hvr, bgamari, austin, goldfire, simonmar

Reviewed By: bgamari

Subscribers: Phyx, rwbarton, thomie

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

Michal Terepeta authored Jul 28, 2017 and Ben Gamari committed Jul 28, 2017

This is another change needed for #13825

 (also based on D38 by Simon
Marlow).

With the change, we count the stack depth in bytes (instead of words).
We also introduce some `newtype`s to help with the change.

Note that this only changes how `ByteCodeGen` works and shouldn't
affect the generated bytecode.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar, austin, hvr

Reviewed By: bgamari, simonmar

Subscribers: rwbarton, thomie

GHC Trac Issues: #13825

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

Michal Terepeta authored Jul 11, 2017 and Ben Gamari committed Jul 11, 2017

This is based on unfinished work in D38 started by Simon Marlow and is
the first step for fixing #13825

. (next step use byte-indexing for
stack)

The change boils down to adjusting everything in BCEnv by +1, which
simplifies the code a bit.

I've also looked into a weird stack adjustement that we did in
`getIdValFromApStack` and moved it to `ByteCodeGen` to just keep
everything in one place. I've left a comment about this.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: austin, hvr, bgamari, simonmar

Reviewed By: bgamari, simonmar

Subscribers: simonmar, rwbarton, thomie

GHC Trac Issues: #13825

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

Ben Gamari authored Jun 27, 2017 and Ben Gamari committed Jun 27, 2017

Reviewers: austin, hvr, erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie

GHC Trac Issues: #8281, #13730.

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

Ryan Scott authored Jun 02, 2017 and Ben Gamari committed Jun 02, 2017

While investigating #12545, I discovered several places in the code
that performed length-checks like so:

```
length ts == 4
```

This is not ideal, since the length of `ts` could be much longer than 4,
and we'd be doing way more work than necessary! There are already a slew
of helper functions in `Util` such as `lengthIs` that are designed to do
this efficiently, so I found every place where they ought to be used and
did just that. I also defined a couple more utility functions for list
length that were common patterns (e.g., `ltLength`).

Test Plan: ./validate

Reviewers: austin, hvr, goldfire, bgamari, simonmar

Reviewed By: bgamari, simonmar

Subscribers: goldfire, rwbarton, thomie

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

takano-akio authored Jan 18, 2017 and Ben Gamari committed Jan 20, 2017

This commits relaxes the invariants of the Core syntax so that a
top-level variable can be bound to a primitive string literal of type
Addr#.

This commit:

* Relaxes the invatiants of the Core, and allows top-level bindings whose
  type is Addr# as long as their RHS is either a primitive string literal or
  another variable.

* Allows the simplifier and the full-laziness transformer to float out
  primitive string literals to the top leve.

* Introduces the new StgGenTopBinding type to accomodate top-level Addr#
  bindings.

* Introduces a new type of labels in the object code, with the suffix "_bytes",
  for exported top-level Addr# bindings.

* Makes some built-in rules more robust. This was necessary to keep them
  functional after the above changes.

This is a continuation of D2554.

Rebasing notes:
This had two slightly suspicious performance regressions:

* T12425: bytes allocated regressed by roughly 5%
* T4029: bytes allocated regressed by a bit over 1%
* T13035: bytes allocated regressed by a bit over 5%

These deserve additional investigation.

Rebased by: bgamari.

Test Plan: ./validate --slow

Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari

Reviewed By: trofi, simonpj, bgamari

Subscribers: trofi, simonpj, gridaphobe, thomie

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

GHC Trac Issues: #8472

This commit implements the proposal in
https://github.com/ghc-proposals/ghc-proposals/pull/29 and
https://github.com/ghc-proposals/ghc-proposals/pull/35.

Here are some of the pieces of that proposal:

* Some of RuntimeRep's constructors have been shortened.

* TupleRep and SumRep are now parameterized over a list of RuntimeReps.
* This
means that two types with the same kind surely have the same
representation.
Previously, all unboxed tuples had the same kind, and thus the fact
above was
false.

* RepType.typePrimRep and friends now return a *list* of PrimReps. These
functions can now work successfully on unboxed tuples. This change is
necessary because we allow abstraction over unboxed tuple types and so
cannot
always handle unboxed tuples specially as we did before.

* We sometimes have to create an Id from a PrimRep. I thus split PtrRep
* into
LiftedRep and UnliftedRep, so that the created Ids have the right
strictness.

* The RepType.RepType type was removed, as it didn't seem to help with
* much.

* The RepType.repType function is also removed, in favor of typePrimRep.

* I have waffled a good deal on whether or not to keep VoidRep in
TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
represented in RuntimeRep, and typePrimRep will never return a list
including
VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
imagine another design choice where we have a PrimRepV type that is
PrimRep
with an extra constructor. That seemed to be a heavier design, though,
and I'm
not sure what the benefit would be.

* The last, unused vestiges of # (unliftedTypeKind) have been removed.

* There were several pretty-printing bugs that this change exposed;
* these are fixed.

* We previously checked for levity polymorphism in the types of binders.
* But we
also must exclude levity polymorphism in function arguments. This is
hard to check
for, requiring a good deal of care in the desugarer. See Note [Levity
polymorphism
checking] in DsMonad.

* In order to efficiently check for levity polymorphism in functions, it
* was necessary
to add a new bit of IdInfo. See Note [Levity info] in IdInfo.

* It is now safe for unlifted types to be unsaturated in Core. Core Lint
* is updated
accordingly.

* We can only know strictness after zonking, so several checks around
* strictness
in the type-checker (checkStrictBinds, the check for unlifted variables
under a ~
pattern) have been moved to the desugarer.

* Along the way, I improved the treatment of unlifted vs. banged
* bindings. See
Note [Strict binds checks] in DsBinds and #13075.

* Now that we print type-checked source, we must be careful to print
* ConLikes correctly.
This is facilitated by a new HsConLikeOut constructor to HsExpr.
Particularly troublesome
are unlifted pattern synonyms that get an extra void# argument.

* Includes a submodule update for haddock, getting rid of #.

* New testcases:
  typecheck/should_fail/StrictBinds
  typecheck/should_fail/T12973
  typecheck/should_run/StrictPats
  typecheck/should_run/T12809
  typecheck/should_fail/T13105
  patsyn/should_fail/UnliftedPSBind
  typecheck/should_fail/LevPolyBounded
  typecheck/should_compile/T12987
  typecheck/should_compile/T11736

* Fixed tickets:
  #12809
  #12973
  #11736
  #13075
  #12987

* This also adds a test case for #13105. This test case is
* "compile_fail" and
succeeds, because I want the testsuite to monitor the error message.
When #13105 is fixed, the test case will compile cleanly.

Shea Levy authored Dec 20, 2016 and Tamar Christina committed Dec 20, 2016

Summary:
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.

This was originally added in https://phabricator.haskell.org/D2826
but that led to a compatibility issue with ghc 7.10.x on Windows.
That's fixed here and the revert reverted.

Reviewers: goldfire, hvr, austin, bgamari, Phyx

Reviewed By: Phyx

Subscribers: thomie

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

GHC Trac Issues: #13008

This reverts commit 52ba9470.

Shea Levy authored Dec 17, 2016 and Ben Gamari committed Dec 17, 2016

Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.

Reviewers: simonmar, goldfire, austin, hvr, bgamari

Reviewed By: simonmar

Subscribers: RyanGlScott, mpickering, angerman, thomie

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

Simon Marlow authored Jul 21, 2016 and Simon Marlow committed Jul 22, 2016

When loading a large number of modules into GHCi, we collect
CompiledByteCode for every module and then link it all at the end.
Space leaks in the CompiledByteCode linger until we traverse it all for
linking, and possibly longer, if there are bits we don't look at.

This is the nuke-it-from-orbit approach: we deepseq the whole thing
after code generation. It's the only way to be sure.

Test Plan:
Heap profile of GHCi while loading nofib/real/anna into GHCi, this patch
reduces the peak heap usage from ~100M to ~50M.

Reviewers: hvr, austin, bgamari, erikd

Subscribers: thomie

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

Summary:
This patch implements primitive unboxed sum types, as described in
https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.

Main changes are:

- Add new syntax for unboxed sums types, terms and patterns. Hidden
  behind `-XUnboxedSums`.

- Add unlifted unboxed sum type constructors and data constructors,
  extend type and pattern checkers and desugarer.

- Add new RuntimeRep for unboxed sums.

- Extend unarise pass to translate unboxed sums to unboxed tuples right
  before code generation.

- Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
  code generation when sum values are involved.

- Add user manual section for unboxed sums.

Some other changes:

- Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
  `MultiValAlt` to be able to use those with both sums and tuples.

- Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
  wrong, given an `Any` `TyCon`, there's no way to tell what its kind
  is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.

- Fix some bugs on the way: #12375.

Not included in this patch:

- Update Haddock for new the new unboxed sum syntax.

- `TemplateHaskell` support is left as future work.

For reviewers:

- Front-end code is mostly trivial and adapted from unboxed tuple code
  for type checking, pattern checking, renaming, desugaring etc.

- Main translation routines are in `RepType` and `UnariseStg`.
  Documentation in `UnariseStg` should be enough for understanding
  what's going on.

Credits:

- Johan Tibell wrote the initial front-end and interface file
  extensions.

- Simon Peyton Jones reviewed this patch many times, wrote some code,
  and helped with debugging.

Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
           simonmar, hvr, erikd

Reviewed By: simonpj

Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
             thomie, mpickering

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

seraphime authored Jul 20, 2016 and Ben Gamari committed Jul 20, 2016

This fixes #12128.

The bug was introduced in 1c9fd3f1.

Test Plan: ./validate

Reviewers: simonmar, austin, hvr, simonpj, bgamari

Reviewed By: bgamari

Subscribers: simonpj, thomie

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

GHC Trac Issues: #12128

These get annoying when `undefined` is actually used as placeholder in WIP code.
Some of these were also completely redundant (just call `deAnnotate'` instead of
`deAnnotate` etc.).

When faced runtime-rep-polymorphic code from a pattern-synonym
matcher, the bytecode generator was treating the result as lifted,
which it isn't.  The fix is just to treat those rep-polymorphic
continuations like unlifted types, and add a dummy arg.

Trac #12007 is a case in point.

It changed from VarSet to DVarSet some time ago.

Ben Gamari authored Mar 23, 2016 and Ben Gamari committed Mar 24, 2016

This adds timings and allocation figures to the compiler's output when
run with `-v2` in an effort to ease performance analysis.

Todo:
  * Documentation
  * Where else should we add these?
  * Perhaps we should remove some of the now-arguably-redundant
    `showPass` occurrences where they are
  * Must we force more?
  * Perhaps we should place this behind a `-ftimings` instead of `-v2`

Test Plan: `ghc -v2 Test.hs`, look at the output

Reviewers: hvr, goldfire, simonmar, austin

Reviewed By: simonmar

Subscribers: angerman, michalt, niteria, ezyang, thomie

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

Summary:
This makes a big performance difference especially when loading a
large number of modules and using parallel compilation (ghci -jN).

Test Plan:
* validate
* `ghci -fexternal-interpreter` in `nofib/real/anna`

Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd

Subscribers: thomie

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

GHC Trac Issues: #11100

Ömer Sinan Ağacan authored Jan 27, 2016 and Ben Gamari committed Jan 27, 2016

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

Summary:
The main goal here is enable stack traces in GHCi.  After this change,
if you start GHCi like this:

  ghci -fexternal-interpreter -prof

(which requires packages to be built for profiling, but not GHC
itself) then the interpreter manages cost-centre stacks during
execution and can produce a stack trace on request.  Call locations
are available for all interpreted code, and any compiled code that was
built with the `-fprof-auto` familiy of flags.

There are a couple of ways to get a stack trace:

* `error`/`undefined` automatically get one attached
* `Debug.Trace.traceStack` can be used anywhere, and prints the current
  stack

Because the interpreter is running in a separate process, only the
interpreted code is running in profiled mode and the compiler itself
isn't slowed down by profiling.

The GHCi debugger still doesn't work with -fexternal-interpreter,
although this patch gets it a step closer.  Most of the functionality
of breakpoints is implemented, but the runtime value introspection is
still not supported.

Along the way I also did some refactoring and added type arguments to
the various remote pointer types in `GHCi.RemotePtr`, so there's
better type safety and documentation in the bridge code between GHC
and ghc-iserv.

Test Plan: validate

Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd

Subscribers: thomie

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

GHC Trac Issues: #11047, #11100

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.

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