GitLab

 * Also fix a nasty bug when creating fixup code that has a cyclic
   register movement graph.

 - In the GNU assembler they mean the same thing
 - The Solaris assembler only has .skip

Following Trac #2905, we now require -XGADTs for *pattern matches* on
GADTs, not just on *definitions*.

Also I found that -XGADTs wasn't being checked when declaring type families,
so I fixed that too.

I followed the suggestion in Trac #2994, which took longer than I
expected.  As usual I did a bit of tidying up at the same time,
and improved a few other error reports.

it shouldn't be there, and might hide bugs

A bug in the constraint simplifier means that an equality can be solved
twice.  It's harmless, and will go away with the new constraint simplifier.
Hence warning, to avoid unnecessary outright failure on eg Trac #2999.

If we float a binding out of a *value* lambda, the fixing-up of IdInfo
is a bit more complicated than before.  Since in principle FloatOut
can do this (and thus can do full lambda lifting), it's imporrtant
that transferPolyIdInfo does the Right Thing.

This doensn't matter unless you use FloatOut's abilty to lambda-lift, 
which GHC mostly doesn't, yet.  But Max used it and tripped over this bug.

Max Bolingbroke suggested these two small improvements to LiberateCase
(most of the size increase is comments :-)):

a) Do LiberateCase on small functions even if they are mutually recursive
   See Note [Small enough]

b) Don't do LiberateCase on functions for which it'd be fruitless,
   namely when a free varible is scrutinised *outside* the function
   See Note [Avoiding fruitless liberate-case]

There is virtually no effect on nofib, but Max tripped over cases
where it mattered slightly.

This patch deals with the following remark

     Suppose we have
            type family T a :: * -> *
            type instance T Int = []

     and now we encounter the type (T Int Bool).  If we call
     lookupFamInstEnv on (T Int Bool) we'll fail, because T has arity 1.
     Indeed, I *think* it's a precondition of lookupFamInstEnv that the
     supplied types exactly match the arity of the type function.  But
     that precondition is neither stated, nor is there an assertion to
     check it.

With this patch, lookupFamInstEnv can take "extra" type arguments in
the over-saturated case, and does the Right Thing.

There was a nearly-identical function lookupFamInstEnvUnify, which
required the precisely analogous change, so I took the opportunity 
to combine the two into one function, so that bugs can be fixed in one
place.  This was a bit harder than I expected, but I think the result
is ok.  The conflict-decision function moves from FamInst to FamInstEnv.
Net lines code decreases, although there are more comments.

Suppose we have
        type family T a :: * -> *
        type instance T Int = []

and now we encounter the type (T Int Bool).  That is perfectly
fine, even though T is over-saturated here.

This patch makes lookupFamInstEnv robust to such over-saturation.
Previously one caller (TcTyFuns.tcUnfoldSynFamInst) dealt with
the over-saturation case, but the others did not. It's better
to desl with the issue at the root, in lookupFamInstEnv itself.

It will use TH, so needs to be built with stage2.

I noticed while working on the new IO library that GHC was writing out
the .s file in lots of little chunks.  It turns out that this is a
result of using multiple printDocs to avoid space leaks in the NCG,
where each printDoc is finishing up with an hFlush.  

What's worse, is that this makes poor use of the optimisation inside
printDoc that uses its own buffering to avoid hitting the Handle all
the time.

So I hacked around this by making the buffering optimisation inside
Pretty visible from the outside, for use in the NCG.  The changes are
quite small.

so that exceptions are reported with "*** Exception" instead of as a panic.

Adopt the suggestion of Trac #2993, and tidy up the reporting of
precedence parsing errors somewhat.

This patch is a straightforward extension of the 'deriving' mechanism.
The ability to derive classes Functor, Foldable, Traverable is controlled
by a single flag  -XDeriveFunctor.  (Maybe that's a poor name.)

Still to come: documentation

Thanks to twanvl for developing the patch

We get caught by
    http://savannah.gnu.org/bugs/index.php?1516
    $(eval ...) inside conditionals causes errors
with make 3.80, so warn the user if it looks like they're about to
try to use it.

The Note [Recursive instances and superclases] explains the subtle
issues to do with generating the bindings for superclasses when
we compile an instance declaration, at least if we want to do the
clever "recursive superclass" idea from the SYB3 paper.

The old implementation of tcSimplifySuperClasses stumbled when
type equalities entered the picture (details in the Note); this
patch fixes the problem using a slightly hacky trick.  When we
re-engineer the constraint solver we'll want to keep an eye on 
this.

Probably worth merging to the 6.10 branch.

Ensuring that 
  a) lambdas show up only on the RHSs of binding after CorePrep
  b) the arity of a binding exactly matches the maifest lambdas
is surprisingly tricky.

I got it wrong (again) in my recent CorePrep shuffling, which broke
packages HTTP and DPH.  This patch fixes both.

They are GFDLed, which causes problems for Debian

The problem is that we install the client's CWD before calling
runStmt, but runStmt has to load modules before running the code.  We
need to install the CWD just before running the code instead, which
means it has to be done inside runStmt (and resume).

From #2951

In this version, I untag R1 before using it, and even enter R2 at the
end rather than simply returning it (which didn't work right when R2
was a thunk).