Specifically, the following sub-repos/modules are converted:

 - libffi-tarballs
 - libraries/array
 - libraries/deepseq
 - libraries/directory
 - libraries/dph
 - libraries/filepath
 - libraries/haskell2010
 - libraries/haskell98
 - libraries/hoopl
 - libraries/hpc
 - libraries/old-locale
 - libraries/old-time
 - libraries/parallel
 - libraries/process
 - libraries/stm
 - libraries/unix
 - nofib
 - utils/hsc2hs

N.B. ghc-tarballs is not converted as it will probably be handled
     differently in the future.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

The fix in c1035d51 (addressing #9231) was done under the assumption
that `Data.Fixed` is used only with power-of-10 `resolution`. This
follow-up fixup changes the behavior to be more consistent with the
previous behavior in GHC 7.6

For instance, for the following `B7` resolution

   > data B7
   > instance HasResolution B7 where resolution _ = 128

After this patch, the following behavior is now observable:

   > 1.070 :: Fixed B7
   1.062
   > 1.062 :: Fixed B7
   1.054

   > read "1.070" :: Fixed B7
   1.062
   > read "1.062" :: Fixed B7
   1.054

This doesn't provide the desirable "read . show == id" property
yet (which didn't hold in GHC 7.6 either), but at least `fromRational`
and `read` are consistent.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Summary:
Add more primops for atomic ops on byte arrays

Adds the following primops:

 * atomicReadIntArray#
 * atomicWriteIntArray#
 * fetchSubIntArray#
 * fetchOrIntArray#
 * fetchXorIntArray#
 * fetchAndIntArray#

Makes these pre-existing out-of-line primops inline:

 * fetchAddIntArray#
 * casIntArray#

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is just documentation for the fix to Trac #9161

`convertFixed` operates under the wrong assumption that
`Data.Fixed.resolution` returns a base-10 exponent `e`, whereas it
actually returns the power-of-10 value `10^e`.

So while the code (that was introduced in 5f19f951 / #7483) happens to
compute a correct result by coincidence, it allocates huge integer values
in the process (i.e. `10^(10^e)`) which cause long computations which
eventually result in out-of-memory conditions for `e`-values beyond
`Data.Fixed.Milli`.

A proper long-term fix would probably be to extend the `HasResolution`
type-class to have a 2nd method providing the `e` value.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

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

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

this seems to be expected, as explained by SPJ in comment 7 of #9208.

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

I forgot to amend this to my last commit.

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

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

Summary:
Previously, on -v4  and greater, we dumped out the entire package
database, including lots of metadata that GHC doesn't really care about,
and is guaranteed to correspond to the equivalent in the local/global
package databases on disk.  So, to make this output more useful, on -v4
we instead just print package IDs, and the exposed and trusted flags
(E and T, which can be tweaked at runtime).

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: successful validate

Reviewers: simonpj

Subscribers: simonmar, relrod

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

This is needed to give meaningful error messages (instead of internal
panics) when a program tries to lift a pattern synonym into a kind.
(fixes T9161)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes Trac #9196.  Thanks to archblob for an initial stab at this.
In the end I fixed it in the kind checker rather than the subsequent
validity check, (a) so that the error messages look more uniform,
and (b) so that I did not need to meddle with isPredTy.

The issue here is avoiding a GHC crash when a program uses
unsafeCoerce is a dangerous (or even outright-wrong) way.

See Trac #9208

See #9206

See Trac #9216

This covers things like
   Eq a => blah   and   (?x::Int) => blah
where there is just one predicate. Previously we used an ad-hoc
test to decide whether to parenthesise it, but acutally there is
a much simpler solution: just use the existing precedence mechamism.

This applies both to Type and HsType.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Updates submodule

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Only comments:  add notes explaining the various oddities of the `Typeable` implementation for type-level literals.

Updates submodule.

Not sure if my patch changed this, but it looks reasonable.

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: simonmar, relrod

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

Summary:
Every time we called typeRep on a type application, we were
recomputing the TypeRep.  This showed up in a benchmark I had: #9203.

Test Plan: Benchmark from #9203.

Reviewers: simonpj, austin

Subscribers: simonmar, relrod

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