Now, on a closed type family, two branches are considered compatible
if their RHSs **normalize** to the same type. Previously, the RHSs
had to be identical (under the unifying substitution). This allows
more reductions -- yay.

CAVEAT: This is probably not type-safe with UndecidableInstances.
Someone (er... me) has to Think Hard about this before merging.
It might be unsafe even with imported non-terminating instances
(so, without UndecidableInstances in the same module).
There's a change this isn't type-safe even without UndecidableInstances,
but I'm not too worried about that possibility.

FamInstEnv.normaliseTcApp should normalise arguments even when
the top-level tycon isn't a type family. This was a regression
from 7.6 -- not sure when it happened, but it was probably my
fault. Fixed now, in any case.

Previously, the closed type family compatibility check was
done even when type-checking an interface file. But interface
files now store compatibility info, so this check was redundant.

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

The fix was to ghc-prim.

to keep validate working.

The inline allocation version is 69% faster than the out-of-line
version, when cloning an array of 16 unit elements on a 64-bit
machine.

Comparing the new and the old primop implementations isn't
straightforward. The old version had a missing heap check that I
discovered during the development of the new version. Comparing the
old and the new version would requiring fixing the old version, which
in turn means reimplementing the equivalent of MAYBE_CG in StgCmmPrim.

The inline allocation threshold is configurable via
-fmax-inline-alloc-size which gives the maximum array size, in bytes,
to allocate inline. The size does not include the closure header size.

Allowing the same primop to be either inline or out-of-line has some
implication for how we lay out heap checks. We always place a heap
check around out-of-line primops, as they may allocate outside of our
knowledge. However, for the inline primops we only allow allocation
via the standard means (i.e. virtHp). Since the clone primops might be
either inline or out-of-line the heap check layout code now consults
shouldInlinePrimOp to know whether a primop will be inlined.

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

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

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

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

(I recall that this was needed in some cases in the past, and might fix
the validate error on travis.)

gcptr should only be used for pointers that the GC should
follow. While this didn't cause any bugs right now, since these
variables aren't live over a GC, it's clearer to use the right type.

interface contents

This is so that generated names like e.g. workers don't show up as
infix operators when using something like -ddump-simpl.

This is done with two built-in type families: `CmpNat and `CmpSymbol`.
Both of these return a promoted `Ordering` type (EQ, LT, or GT).

For DFunUnfoldings we were failing to occurrence-analyse the unfolding,
and that meant that a loop breaker wasn't marked as such, which in turn
meant it was inlined away when it still had occurrence sites.  See
Note [Occurrrence analysis of unfoldings] in CoreUnfold.

This is a pretty long-standing bug, happily nailed by John Lato.

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

I moved the "promoted literals" sub-section into a separate section,
as many folks were not finding the docs.  I also added some additional
paragraphs describing the current state of the feature.

We don't yet understand WHY commit ad15c2, which is to do with
CmmSink, causes seg-faults on Windows, but it certainly seems to.  So
reverting it is a stop-gap, but we need to un-block the 7.8 release.

Many thanks to awson for identifying the offending commit.

There was even a comment to warn about this possiblity,
and it finally showed up in practice!  This patch fixes
it quite nicely, with commens to explain.

This partly reverts commit e239753c. Since
Coercible is exported via GHC.Types, so "primclass" is no longer
needed. The support for => in primops.pp is still required for coerce.

so do not export it in GHC.Prim, and also have the pseudo-code for
GHC.Prim import GHC.Types, so that haddock is happy.

(Unchecked comment-only commits should better use the right commenting
style...)

This prepares against future breakage, especially if #8894 is tackled.

This is a followup to the fix for #8827, and should be merged
with that change.

Even if the recursion is a nice tail-call only recusion, we'd stil be
calling the thunk multiple times and eta-expansion would be wrong.
Includes a [Note].

(Also shows the disadvantage of unit tests: They had the same bug.)