It's now always 'git'.

We no longer set BootingFromHc

Most of it was commented out anyway

The typechecking of arrow forms (in GHC 7.6) is known to be bogus, as
described in Trac #5609, because it marches down tuple types that may
not yet be fully worked out, depending on when constraint solving
happens.  Moreover, coercions are generated and simply discarded.  The
fact that it works at all is a miracle.

This refactoring is based on a conversation with Ross, where we
rearranged the typing of the argument stack, so that the arrows
have the form
   a (env, (arg1, (arg2, ...(argn, ())))) res
rather than
   a (arg1, (arg2, ...(argn, env))) res
as it was before.

This is vastly simpler to typecheck; just look at the beautiful,
simple type checking of arrow forms now!

We need a new HsCmdCast to capture the coercions generated from
the argument stack.

This leaves us in a better position to tackle the open arrow tickets
 * Trac #5777 still fails.  (I was hoping this patch would cure it.)
 * Trac #5609 is too complicated for me to grok.  Ross?
 * Trac #344
 * Trac #5333

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Originally we had the invariant that CTyEqCan and CFunEqCan have LHS
and RHS with compatible kinds.  This is important because if they have
different kinds, then a substitution using the CTyEqCan can give rise
to an ill-kinded type, which in turn makes typeKind crash, and this
led to Trac #7696.  (The possibility of this happening really only
occurred when we introduced kind polymorphism.)

I thought at first this was going to be really awkward to solve, but
happily it turned out to be easy.  We already have CIrredEvCan
constraints, which are "stuck"; we can't use them and we can't solve
them.  Yet. After some substitution from solving other constraints we
may be able to make progress.

So for equality constraints where the LHS and RHS don't have compatible kinds
(although perhaps not YET compatible, eg k and *, just needing to
unify k := *), we now generate a CIrredEvCan, plus the necessary kind
equality constraint.

This entailed some refactoring of course, but only in TcCanonical.  In
particular, the emitKindConstraint code has gone, in favour of a kind
check in canEqLeaf.  See Note [Equalities with incompatible kinds] in
TcCanonical, and Note [CIrredEvCan constraints] in TcRnTypes

This was causing the bug reported in Trac #7697

We now define _PROGNAME, and _PROG is automatically defined with
$(exeext). This will shortly automatically use the right exeext
depending on what stage it is being compiled with (exeext may be
different for different stages when cross-compiling).

and use them for split

It doesn't seem to do anything that _INSTALL and _INSTALL_INPLACE
can't do.

We don't need them, but GHC API users might.

Patch from monoidal

Patch from Stephen Blackheath.

This is sometimes needed when cross-compiling, as some packages may be
built in stage 0 but not stage 1.

In order to make everything work out, this also removes the requirement
that the build-dirs are in dependency order

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

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

Doesn't look like it causes any failures in the full test suite, so
presumably it's fine!

Patch from Stephen Blackheath