GitLab

see comment for details

This fixes a problem with commands like gzip, where if $GZIP is exported
in the environment, then when make runs a command it'll put the Makefile
variable's value in the environment. But gzip treats $GZIP as arguments
for itself, so when we run gzip it thinks we're giving it "gzip" as an
argument.

This lets automatic prefetching work better, for a tiny performance boost

Get the set of free variables from the generated case expression:
includes variables in the guards and decls that were missed before,
and is also a bit simpler.

This was done as part of an honours thesis at UNSW, the paper describing the
work and results can be found at:

http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf

A Homepage for the backend can be found at:

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM

Quick summary of performance is that for the 'nofib' benchmark suite, runtimes
are within 5% slower than the NCG and generally better than the C code
generator.  For some code though, such as the DPH projects benchmark, the LLVM
code generator outperforms the NCG and C code generator by about a 25%
reduction in run times.

GHCi was building its GlobalRdrEnv wrongly, so that the
gre_par field was bogus.  That in turn fooled the renamer.
The fix is easy: use the right function!  Namely, call
RnNames.gresFromAvail rather than availsToNameSet.

This was just a blatant omission, which hasn't come up before.
Easily fixed, happily.

Now we only want about "T is a type function and might not be
injective" when matchin (T x) against (T y), which is the case
that is really confusing.

This is a long-lurking bug that has been flushed into
the open by other arity-related changes.  There's a
long comment

     Note [CafInfo and floating]

to explain.  

I really hate the contortions we have to do through to keep correct
CafRef information on top-level binders.  The Right Thing, I believe,
is to compute CAF and arity information later, and merge it into the
interface-file information when the latter is generated.

But for now, this hackily fixes the problem.

In cpePair I did things in the wrong order so that something that
should have been a CprRhs wasn't.  Result: a crash in CoreToStg.
Fix is easy, and I added more informative type signatures too.

See Note [DFun unfoldings] in CoreSyn.  The issue here is that 
you can't tell how many dictionary arguments a DFun needs just
from looking at the Arity of the DFun Id: if the dictionary is
represented by a newtype the arity might include the dictionary
and value arguments of the (single) method.

So we need to record the number of arguments need by the DFun
in the DFunUnfolding itself.  Details in 
   Note [DFun unfoldings] in CoreSyn

Just putting parens around non-atomic expressions isn't sufficient
for splices, as only the $x and $(e) forms are valid input.

We now get an exception if the path doesn't exist