GitLab

The new stg_gc_prim_p_ll stack frame was missing an info table.  This
is a regression since 7.6, because this stuff was part of a cleanup
that happened in 7.7.

We now display the foralls of a type if any of the type variables
is polykinded.  This put kind polymorphism "in your face" a bit more
often, but eliminates a lot of head scratching.

The user manual reflects the new behaviour.

The provided tests test both annotation generation and reification
from Template Haskell.  Both --make and compilation via separate
units (ghc -c) are tested.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Many of these have never been initialised, I think.  They
were simply guesses from the 64-bit version.

The argument in Trac #9033 is very compelling: we should not report 20
errors, fix one, and have the other 19 disappear.  They were spurious
in the first place.

The fix was easy; do type-class defaulting uncondionally, rather than
only if there are no insoluble constraints.

See Note [When to do type-class defaulting] in TcSimplify.

Error messages generally improve, especially tc211 which actually
had an example of precisely this phenomenon.

This is an attempt to address

  https://github.com/haskell/cabal/issues/1811



by replicating the less than 100 lines of code actually used from the
containers package into an internal non-exposed `template-haskell` module.

Moreover, `template-haskell` does not expose the `Map` type, so this change
should have no visible effect on the public API.

It may turn out that `Data.Map` is not necessary and that even a simple
list-based associative list (`Prelude.lookup`) may suffice. However, in
order to avoid any regressions, this commit takes the safe route and just
clones `Data.Map` for now.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

See Note [Do not eta-expand PAPs] in SimplUtils.  This has a tremendously
good effect on compile times for some simple benchmarks.

The test is now where it belongs, in perf/compiler/T9020 (instead of simpl015).

I did a nofib run and got essentially zero change except for cacheprof which
gets 4% more allocation.  I investigated.  Turns out that we have

    instance PP Reg where
       pp ppm ST_0 = "%st"
       pp ppm ST_1 = "%st(1)"
       pp ppm ST_2 = "%st(2)"
       pp ppm ST_3 = "%st(3)"
       pp ppm ST_4 = "%st(4)"
       pp ppm ST_5 = "%st(5)"
       pp ppm ST_6 = "%st(6)"
       pp ppm ST_7 = "%st(7)"
       pp ppm r    = "%" ++ map toLower (show r)

That (map toLower (show r) does a lot of map/toLowers.  But if we inline show
we get something like

       pp ppm ST_0 = "%st"
       pp ppm ST_1 = "%st(1)"
       pp ppm ST_2 = "%st(2)"
       pp ppm ST_3 = "%st(3)"
       pp ppm ST_4 = "%st(4)"
       pp ppm ST_5 = "%st(5)"
       pp ppm ST_6 = "%st(6)"
       pp ppm ST_7 = "%st(7)"
       pp ppm EAX  = map toLower (show EAX)
       pp ppm EBX  = map toLower (show EBX)
       ...etc...

and all those map/toLower calls can now be floated to top level.
This gives a 4% decrease in allocation.  But it depends on inlining
a pretty big 'show' function.

With this new patch we get slightly better eta-expansion, which makes
a function look slightly bigger, which just stops it being inlined.
The previous behaviour was luck, so I'm not going to worry about
losing it.

I've added some notes to nofib/Simon-nofib-notes

Previously we always printed qualified names, but that makes a lot of debug or
warning output very verbose. So now we only print qualified names with -dppr-debug.

Civilised output (from pukka error messages, with the environment available) is
unaffected

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

Now that we're in development mode, Applicative will soon be a
superclass of Monad in HEAD. So let's go ahead and deprecate the
-fno-warn-amp flag, remove the checks, and tweak a few tests
Signed-off-by: Austin Seipp <austin@well-typed.com>

Update several old

  http://hackage.haskell.org/trac/ghc

URLs references to the current

  http://ghc.haskell.org/trac/ghc



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

This checks that all the required extensions are enabled for the
inferred type signature.

Updates binary and vector submodules.

In the rather gnarly filterImports code, someone had forgotten
the AvailTC invariant:  in AvailTC n [n,s1,s2], the 'n' is itself
included in the list of names.

The testsuite reference output for ghcpkg01 needs to be adapted
since a "More diff friendly pretty printing of cabal files"
is now performed.

Fixes Trac #8987.  See Note [Exceptions in TH]

Thanks to Yuras Shumovich for doing this.

in pattern synonym definitions

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

In tidying up the flattener I introduced an error that no
regression test caught, giving rise to Trac #8978, #8979.
It shows up if you have a type synonym whose RHS mentions
type functions, such sas
     type family F a
     type T a = (F a, a)   -- This synonym isn't properly flattened

The fix is easy, but sadly the bug is in the released GHC 7.8.1

check_stdout(f) allows you to override the test framework's
diff based output checking with another mechanism.  f is
a function which takes two arguments: the first is the
filename containing the observed stdout, the second is the
normaliser that would have been applied (in case you want
to read, normalise, and then do something.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This change adds a suggestion
    Possible fix: add a type signature for ‘f’
when we have a GADT-style definition with a
type we can't figure out.

See Note [Suggest adding a type signature] in TcErrors.

This initially came up in the discussion of Trac #8968.

This was just an omission, which showed up as Trac #8966

I got sucked into a significant refactoring of the way that
Typeable instances are derived.  This makes it simpler and
more uniform.

I also improved the documentation in the user manual.  Typeable
really is different to other classes, and now gets its own subsection.

Many are improvements!

(#8961)

We now do role inference on stupid datatype contexts, allowing a
lightweight role annotation syntax.

This fixes Trac #8954.

There were actually three places where tuple occ-names
were parsed:
  - IfaceEnv.lookupOrigNameCache
  - Convert.isBuiltInOcc
  - OccName.isTupleOcc_maybe

I combined all three into TysWiredIn.isBuiltInOcc_maybe
Much nicer.

A palpable bug, although one that will rarely bite