These modules are always home modules, by definition, so the package
name is redundant.

For the benefit of old GHCs that don't understand {-# UNPACK #-}

The ordering of items in the parsed export list is now correct, so we
have to compensate to get the right output again.

From David's email:
The problem is that the inline assembler code was placing the result
of an operation in a register that is used as input later in the code.
At the bottom of this message I've extracted a short short code
fragment that you can run through gcc (on a powerpc machine) to see
the generated assembly output.

The changes to fix the problem are fairly simple.  The first adds an
ampersand to the output list of the assembly fragment ("=r" (result)
--> "=&r" (result)) The ampersand just tells gcc that result can not
be placed in a register used for any of the input parameters (o, n, or
p).  Otherwise, it feels free to place output parameters in the same
registers used by the inputs -- but because of the flow of control
here we need everything in a distinct register.  This change fixes the
TVar program above.

The second change adds a clobber list (the :"cc", "memory").  This
tells gcc that the condition code (due to the compare) and memory (due
to the store) might be changed during the asm execution.  The lack of
a clobber list did not seem to be causing any trouble, but without it
gcc is free to assume that no state is changed during the execution.

For some reason this was only enabled when $(bootstrapped)=YES.  This
would be one reason why the stage1 compiler is slow.  I guess we'll
find out if anything goes wrong.

Add mising stage1/ directories to object files touched by hc-build, and
give stage=1 as an argument to make install.

For a long time, Template Haskell has fallen over in a very un-graceful
way (i.e. panic) even when it encounters a programmer error.  In particular,
when DsMeta converts HsSyn to TH syntax, it may find Haskell code that
TH does not understand. This should be reported as a normal programmer
error, not with a compiler panic!

Originally the desugarer was supposed to never generate error
messages, but this TH desugaring thing does make it do so.  And in
fact, for other reasons, the desugarer now uses the TcRnIf monad, the
common monad used by the renamer, typechecker, interface checker, and
desugarer.  

This patch completes the job, by 
 - allowing the desugarer to generate errors
 - re-plumbing the error handling to take account of this
 - making DsMeta use the new facilities to report error gracefully

Quite a few lines of code are touched, but nothing deep is going on.

Fixes Trac# 760.

See extensive comments with Note [INLINE and NOINLINE] in this file.

A consequence of my recent meddling with hs-boot files is that GHC is
more picky about the correpondence between the hs-boot file and the hs file.
In particular, you must use the same type synonyms.

This patche fixes up GHC's own hs-boot files to match the restriction.

The problem with tagToEnum# is that it is not overloaded (in the
Haskell sense) but you are only supposed to apply it to a TyCon
that is an enumeration (isEnumerationTyCon).

The Real Way to do this is to have some special kind of type constraint
for the purpose, but that is wild overkill. So this patch adds a small
rather ad-hoc check to TcExpr.instFun.  Crude, simple, but it works fine.

Fixes Trac #786
Test is tcfail164

argToPat is a crucial function for SpecConstr, because it decides
what patterns are worth specialising.  I was being much too gung-ho about
constants.  This patch makes it much better.

This refactoring ensures that when mkAtomicArgs adds new bindings,
it does so using completeNonRecX, which adds unfoldings etc.  More
modular, and saves passes too.

(This was important when getting rules to work right.  We want tob
fire a rule as soon as possible, taking into account all inlinings,
else a less-good rule applies.  That's what I found when doing 
stream fusion anyway.)

Regardless, this is an improvement.