When fiddling with pattern-matching for unboxed tuples, I'd messed up
the slightly-tricky tests for pattern matching on unboxed tuples, notably
	case (# foo, bar #) of r -> ...r...

The fix is in TcPat, and test are tcfail115, tcfail120, and tc209

Spotted by Bulat Ziganshin.

We need the #line directives left in, so that Haddock can figure out
what the name of the original source file was called, which is
necessary for generating source links.  You probably now need an
updated Haddock to generate HTML from the libraries, but a release
will be forthcoming shortly.

The handling of top-level names in declaration brackets is a bit tricky.
This commit fixes Trac #977;  test is TH_spliceD2.

The changes are commented in RnExpr.rnBracket and RdrName.hideSomeUnquals

first, I got the dependencies wrong (should be the .o file, not the
.hs), and secondly GHC's recompilation checker refuses to recompile
these files anyway.  I haven't done anything about the second problem
yet, except to comment it.

Some diffs don't understand --strip-trailing-cr.

I had failed to remove the bit where result type signatures bind
lexical type variables.  And now we are planning to remove them entirely.

This commit therefore does a partial removal (to avoid destablising 6.6).
It also arranges that
	f :: sig = rhs
means a *pattern* binding (not a function binding with no arguments 
and a result signature), which makes sense.

Our .depend machinery doesn't automatically generate these, so we have
to add them manually.  (this fixes one instance of missing
dependencies in the GHC build tree, there are lots more...).

These closure types aren't used/needed, as far as I can tell.  The
commoning up of Chars/Ints happens by comparing info pointers, and
the info table for a dynamic C#/I# is CONSTR_0_1.  The RTS seemed
a little confused about whether CONSTR_CHARLIKE/CONSTR_INTLIKE were
supposed to be static or dynamic closures, too.

Not having this check led to strange error messages.
See test rnfail046.

exprIsCheap was already making record selection look cheap, esp for
dictionary selection; e.g.
   (==) dEq

The idea is to allow those record selections to migrate inside a
lambda, because on the whole it's more expensive to share than 
repeat them.

But sometimes dictionary selection is nested; e.g.
   (==) ($p1Num dNum)

This turned out to make a (fragile) rewrite rule fire a little
more robustly, but it seems like a good idea in any case.

This patch makes nested record selections also look cheap.

GHC's design for lexically scoped type variables has changed.
Here, belatedly, is the documentation.

We had
    base=01100000 size=1048576 size_delta=0 it->size=2097152 
    it->base=00F00000 base-it->base=00200000
in commitBlocks.
Esa Ilari Vuokko identified this inequality test as the cause.

We're not going to include cabal-setup and cabal-install in this release.

Fixed version of an old patch by Simon Marlow. His description read:
 Also, now an arbitrarily short context switch interval may now be
 specified, as we increase the RTS ticker's resolution to match the
 requested context switch interval.  This also applies to +RTS -i (heap
 profiling) and +RTS -I (the idle GC timer).  +RTS -V is actually only
 required for increasing the resolution of the profile timer.

GHC 6.5 does enhanced dependency analysis for recursive bindings, to 
maximise polymorphism based on type signatures.  (See Mark Jones's
THIH paper.)  

I didn't do the bindInstsOfLocalFuns part correctly though, and jhc
showed up the bug.  (It only matters when you have a recursive group
of two or more functions with a type signature, not at top level, which
is why it hasn't shown up till now.) 

Test is tc207.hs

There are no functional changes in this commit.  But the code for
derived Read is refactored to make it tidier --- and also to make
it very easy if we want derived Read to parse the prefix form of
infix ocnstructors.  

For example,
	data T = Int `T1` Int
According to the H98 report, the derived Read instance will parse
infix uses of T1, but not prefix uses (T1 4 3).  It's arguable that it
should parse both -- and easy to implement, but it would cause a little bit
of code bloat.

Similarly records.

Anyway this commit doesn't implement the change; just makes it easy
to do so.