I added a new module, Merge, to the ext-core library that combines a list of ext-core modules into a new, uniquely renamed module.

See comments in Merge.hs for more details.

We used to always copy old_size

This suspicious function had just one call, in BuildTyCl.mkNewTyConRhs.
I've done it another way now, which is tidier.

I did the wrong checkSigTyVars, which (happily) triggered an ASSERT
failure.  This should fix it.

In refactoring instance declarations I'd taken a short cut over
scoped type variables, but it wasn't right as #2572 shows.

Fixing it required a significant chunk of further refactoring,
alas. But it's done!  Quite tidily as it turns out.

The main issue is that when typechecking a default method, we
need two sets of type variables in scope
	class C a where
   	  op :: forall b. ...
	  op = e
In 'e', *both* 'a' and 'b' are in scope.  But the type of the
default method has a nested flavour
	op :: forall a. C a => forall b. ....
and our normal scoping mechanisms don't bring 'b' into scope.
(And probably shouldn't.)  

Solution (which is done for instance methods too) is to use
a local defintion, like this:

  $dmop :: forall a. C a => forall b. ....
  $dmop a d = let 
                 op :: forall b. ...
                 op = e
              in op

and now the scoping works out.  I hope I have now see the
last of this code for a bit!

Bryan discovered that a non-trivial record selector (non-trivial in 
the sense that it has to reconstruct the result value because of
UNPACK directives) weren't being inlined.  The reason was that the
unfolding generated by MkId.mRecordSelId was never being optimised
*at all*, and hence looked big, and hence wasn't inlined.

(The out-of-line version *is* put into the code of the module
and *is* optimised, which made this bug pretty puzzling.  But the
unfolding inside the record-selector-Id itself, which is a GlobalId
and hence does not get its inlining updated like LocalIds, was
big and fat.)

Solution: I wrote a very simple optimiser, CoreUnfold.simplOptExpr,
which does enough optimisation to solve this particular problem.
It's short, simple, and will be useful in other contexts.

HsWrappers are horribly inconsistent at the moment. I intended that
  WpLam, WpApp     are for evidence abstraction/application
  WpTyLam, WpTyApp are for type abstraction/application

But when we zonk (WpApp co), where co is a coercion variable, we 
get a *coercion* not a coercion *variable*.   So for now I'm making
it into a WpTyApp, which the desugarer handles perfectly well.

(I'd forgotten to zonk it properly at all; that is the bug that 
this patch fixes.)

When setting implied flags, do so recursively.  So if -Xa implies -Xb,
and -Xb implies -Xc, we do the right thing. 

I thought we needed this, but we don't.  But it seems like a good idea
anyway.

This one was missed when the error-ids all moved to Control.Exception.Base
(The nofib test 'fluid' showed it up.)

See Note [Floating in past a lambda group]. The new thing
here is that we previously were not floating in past a group
that had (\(a:*) \(x:State# a). e), with a type var *and* a
one-shot lambda.  

The fix makes wave4main allocate 2% less, and doesn't change any other
nofib number, so it's not a big deal.

See Note [Inlining in ArgCtxt].  This very small change gives quite a
big performance win. Just showing the bigger ones:

        Program           Size    Allocs   Runtime
--------------------------------------------------------------------------------
           anna          -0.7%     -4.3%      0.15
       cichelli          -0.6%     -6.4%      0.15
         fulsom          -0.4%    -18.5%     -8.1%
            gcd          -0.6%    -12.0%      0.06
        integer          -0.6%    -16.2%     -8.4%
          power          -0.7%    -19.3%     -4.8%
--------------------------------------------------------------------------------
            Min          -0.7%    -19.3%    -15.7%
            Max          -0.1%     +0.1%     +5.7%
 Geometric Mean          -0.6%     -1.9%     -4.3%

The original change was to improve a case that Roman found (see test
eyeball/inline1) but that seems to work ok now anyway.

Fixes crash when using compacting GC in parallel programs

Check that all threads marked as dirty are really on the mutable list.

wakeupThreadOnCapbility() is used to signal another capability that
there is a thread waiting to be added to its run queue.  It adds the
thread to the (locked) wakeup queue on the remote capability.  In
order to do this, it has to modify the TSO's link field, which has a
write barrier.  The write barrier might put the TSO on the mutable
list, and the bug was that it was using the mutable list of the
*target* capability, which we do not have exclusive access to.  We
should be using the current Capabilty's mutable list in this case.

This patch removes old code from the Schedule.c file.

I removed GRAN code for GranSim, a simulator for parallel Haskell execution with GpH model.
This code is inactive since ghc-4.x. 

Code for PARALLEL_HASKELL has been partially removed. The remaining code is valid, but can 
refer to nonexisting functionality in other files.

Two threads were trying to move the same TSO.  I like this test, it
has caught plenty of bugs in the past.

The macros were duplicating their arguments, which was normally
harmless, but in the parallel GC was actually wrong and caused
spurious assertion failures.

Hopefully this will fix the SunOS builbot slave.