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

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

SpecConstr has for a while now looked for types with the built
in ForceSpecConstr annotation, in order to know where to be particularly
aggressive.

Unfortunately using an annotation has a number of downsides, the most
prominent two being:

  A) ForceSpecConstr is vital for efficiency (even if it's
     a hack), but it means users of it must have GHCI - even though
     stage2 features are not required for anything but the annotation.

  B) Any user who might need it (read: vector) has to duplicate the same
     piece of code. In general there are few people actually doing this,
     but it's unclear why they should have to.

This patch makes SpecConstr look for functions applied to the new
GHC.Types.SPEC type - a copy of the already-extant 'SPEC' type - as well
as look for annotations, in the stage2 compiler.

In particular, this means `vector` can now be built with a stage1
compiler, since it no longer depends on stage2 for anything else. This
is particularly important for e.g. iOS cross-compilers.

This also means we should be able to build `vector` earlier in the build
process too, but this patch doesn't address that.

This requires an accompanying bump in ghc-prim.

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

This is suitable e.g. for iOS.

Authored-by: Authored-by: Luke Iannini <lukexi@me.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

Once again the whitespace rules (and the rules concerning expansion of
tokens) have bitten us.

Authored-by: Authored-by: Luke Iannini <lukexi@me.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This includes both executables (by correcly setting the rpath to the
topDir) and libffi, and GHC itself, so that everything works with no
build tree.

Authored-by: Christiaan Baaj <christiaan.baaij@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This is encoded as RtsFlags.GcFlags.maxStkSize == 0.

This requires that stackOverflow() in RtsUtils.c be passed a reference
to the current TSO. This requires a small change in libraries/base.

... plus a couple of unused variables in TcSMonad

There was no useful distinction; a simple refactoring.

We were (uselessly) iterating the simplification loop an exponential
number of times.  Lovely simple test case showed this up.

See Note [Cutting off simpl_loop] in TcSimplify

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

The particular problematic code in #7762 was this:

            nat newSize = size - n;
            char *freeAddr = MBLOCK_ROUND_DOWN(bd->start);
            freeAddr += newSize * MBLOCK_SIZE;
                        ^^^^^^^^^^^^^^^^^^^^^^  OVERFLOW!!!

For good measure, I'm going to fix the bug twice.  This patch fixes
the class of bugs of this kind, by making sure that any expressions
involving BLOCK_SIZE or MBLOCK_SIZE are promoted to unsigned long.  In
a separate patch, I'll fix a bunch of individual instances (including
the one above).

Inlining global registers and constants made code slightly larger in
some cases.  I finally got around to looking into why, and discovered
one reason: we weren't discarding dead code in some cases.  This patch
fixes it.

Also refactor the #defines to hopefully make it clearer what's going
on.

Fixes #8456

A bit of a mess had accumulated, with unclear invariants.

* Remove splitNewTypeRepCo_maybe, in favour of topNormaliseNewType_maybe
  (which had the same signature but behaved subtly differently).

* Make topNormaliseNewType_maybe guaranteed to return a non-newtype
  if it says (Just ty).  This is what was causing the loop in #8467

* Apply similar tidying up to FamInstEnv.topNormaliseType

Trivial fix; matches oprhNamesOfClsInst.

The AMP warnings caused 'base' to be loaded even when we were
compiling 'ghc-prim'.  That is bad, bad, bad.  We got a very
obscure message
   attempting to use module ‛ghc-prim:GHC.Types’
     (libraries/ghc-prim/./GHC/Types.hs) which is not loaded

See Note [Home module load error] in LoadIface

Apologies -- there was some git confusion that cause the Wrong Thing
to happen.

This reverts commit bb9d53e3.

Conflicts:

	compiler/hsSyn/Convert.lhs

Now, instead of looking at a class's roles, the GND check looks
at all of the methods in the class individually. This has the
advantage that sometimes, we can use information about the
derivation requested during the safety check. For example,
we can now derive (IArray UArray), whereas the previous check
prevented this.