Fix TH_reifyType2 test

Comments

Mac OS X/PowerPC: Make GHCi deal with the additional statically linked
symbols from libSystemStub.a on Tiger (printf$LDBLStub and friends).

MERGE TO STABLE

- -package P picks the latest version of P, instead of complaining
    if P is ambiguous.

  - -hide-package P hides all versions of P, instead of complaining
    if P is ambiguous.

- -package P hides all other versions of P (this was advertised
    in the documentation, but wasn't actually implemented in 6.4)

  - if multiple packages with the same name are still exposed after
    the flags have been processed, then all except the latest version
    are hidden.

Fix mulMayOflo() on 64-bit archs.  This fixes the arith003 failures on x86_64.

#include <windows.h>

Handle TREC_CHUNK in update_fwd_large

MERGE to STABLE

Switch the order of equations generated by FunDeps.improve,
so that the error messages are more perspicuous.

This fixes SourceForge [ ghc-Bugs-1234239 ]
  "Bad location for violation of functional dependency"

tcfail143 tests.

Add casts to silence warnings when using Solaris' simple-minded isupper() macro.

Try MERGE to STABLE

When TH splices in code, it was previously decorated with noLoc.  If
there were any type errors in it, we got a very unhelpful message.

Now we propagate the splice location everywhere into the spliced code.
The location isn't very exact, because it refers to the splice site,
but it's better than before.

Add an extra note about defaulting in GHCi

An earlier commit, liberalising the defaulting rules for ghci,
messed up the handling of defaulting at the top level.  This
commit fixes it.

The current story is that if there's an ambiguous top-level
multi-parameter constraint (C a b), then a,b won't be defaulted,
regardless of how a,b are used otherwise.  A type variable is
defaulted only if it's constrained by single-parameter type classes,
even in the more-liberal GHCi.

tcfail142 tests this case.

Give a more helpful error message on platforms for which FFI support
isn't implemented in GHCi (namely x86_64 at the moment).

Fix cut-n-pasto in previous commit

Disable a couple of assertions for the same reason as the previous commit.

Check for an unboxed tuple binding
	f = (# True, False #)

A fairly recent change, that treats specially non-recursive bindings of a
single variable, failed to take this into account.

tcfail141 tests this case.  (Was simpl008.)
-

Comment only

schedulDoGC: when traversing the all_threads list checking for invalid
transactions we were bogusly following the link field rather than the
global_link field.

handle PrimTyCons in pprTyConHdr (fixes :i GHC.Base.Int# in GHCi)

export some more bits

More 64-fixing

64 bit fix

Use stgMallocBytesRWX for allocating info tables, since the memory
needs to be executable (not sure how this is working on OpenBSD right
now, but it definitely breaks on x86_64/Linux).

Move mallocBytesRWX into RtsUtils, rename it to stgMallocBytesRWX, and
export it.

Add some comments on why we don't use posix_memalign() right now.

declare stg_returnToSchedNotPaused (forgot to commit this yesterday)

After some experiments, it seems like we're stealing too many registers from
newer GCCs on SPARC, leading to

   "unable to find a register to spill in class `GENERAL_REGS'"

errors. The fix is to leave l6 and l7 to GCC. Tested with a full 2-stage
bootstrap (including OpenGL/GLUT packages) on SPARC Solaris 8 with GCC 3.4.4.

A test case for this (which I'm too lazy/tired to commit) is:

   module Blah ( foo ) where
   import Foreign.Ptr ( FunPtr )
   type Bar = Int -> Double -> Double -> Double -> IO ()
   foreign import ccall unsafe "dynamic" foo :: FunPtr Bar -> Bar

SimonM: MERGE TO STABLE (if nobody yells)

Avoid calling threadPaused() on exit from STG land if we're just
switching to the interpreter, and conversely call threadPaused() in
the interpreter if we're returing to the scheduler for anything other
than switching to STG.

This will probably fix the recent slowdown in GHCi (ioref001 test, for
example).  It was broken when we moved the threadPaused() call into
STG from the scheduler, so it only affects the HEAD.

make_constr_itbls: 64-bit fix (size of info table was hardcoded)

byte code info tables for x86_64 (same as i386)

Turn on GHCi for x86_64

GHCi staggers to its feet on x86_64.

The problem is that in the small code model on x86_64, all symbol
relocations are 32-bit, because the program is assumed to fit into
2Gb.  However, shared libraries are linked outside the 2Gb range, and
the linker arranges that references to shared library symbols either
go via a jump table (for code references) or are copied into the 2Gb
area (for data references).

In GHCi's linker, We can use a jump table for the function symbols,
but we can't copy the data symbols because they've already been
relocated to point to the shared library.  What's more, we can't tell
whether a symbol reference is to code or data - this information is
only available from the shared library itself.

Fortunately, at least HSbase.o doesn't have any data references to
shared libraries (at least on the Linux distro I'm using), so I can at
least get GHCi up and limping.

awakenBlockedQueue(): check for NULL.  This is a hack to workaround a
bug that occurs when async exceptions, unsafePerformIO, and
interruptible operations are used together.  See the comment in
Exceptions.cmm and bug #1235728 for more details.

Wibbles to unifyFunTy error messages

Improvements to speakN, define speakNOf, move plural from TcSimplify

mingw32: ignore isDoesNotExistError failure from
GHC.ConsoleHandler.flushConsole

Submitted-by: Brian Smith <brianlsmith at gmail.com>

Improve the error message from unifyFunTys.  Previously we got a really
horrible message from this:
	  t = ((\Just x -> x) :: Maybe a -> a) (Just 1)
    
Try.hs:1:6:
    Couldn't match the rigid variable `a' against `t -> t1'
      Expected type: a
      Inferred type: t -> t1

Now it's much better:

Try.hs:14:6:
    The lambda expression `\ Just x -> ...' has two arguments,
    but its type `Maybe a -> a' has only one
    In the expression: (\ Just x -> x) :: Maybe a -> a


tcfail140 tests some cases

Fix a bug in the renamer for parallel list comprehensions
	MERGE TO STABLE

It's surprinsingly tricky to combine 
  a) The parallel scopes for par-list-comps
with
  b) The general form of the renamer types, whereby
     scoped constructs work like
	 rnPat :: Pat -> RnM (thing,FreeVars)
	       -> RnM ((Pat,thing), FreeVars)
     This general shape neatly allows rnPat to
     extend the envt, report unused variables from
     the 'thing' inside, and return the correct set
     of free variables

But combining (a) and (b) is tricky, and was plain wrong before.

Add speakN, and the ability to set printing depth