--------------------------------------------
	Fix another bug in the squash-newtypes story.
	--------------------------------------------

[This one was spotted by Marcin, and is now enshrined in test tc130.]

The desugarer straddles the boundary between the type checker and
Core, so it sometimes needs to look through newtypes/implicit parameters
and sometimes not.  This is really a bit painful, but I can't think of
a better way to do it.

The only simple way to fix things was to pass a bit more type
information in the HsExpr type, from the type checker to the desugarer.
That led to the non-local changes you can see.

On the way I fixed one other thing.  In various HsSyn constructors
there is a Type that is bogus (bottom) before the type checker, and
filled in with a real type by the type checker.  In one place it was
a (Maybe Type) which was Nothing before, and (Just ty) afterwards.
I've defined a type synonym HsTypes.PostTcType for this, and a named
bottom value HsTypes.placeHolderType to use when you want the bottom
value.

Fix the module import story to match what the Revised
Haskell Report says

1. 	Don't import qualified names of things that aren't imported

2.	Fix a bug that meant
		import A hiding( D )
	where D is a data constructor, didn't work.
	[The fix is to use IEVar not IEThingAbs in the
	want_hiding case of get_item in RnNames.filterImports

Rewire so that hsc.c files get built as part of cbits library.

Fix spacing

Two fixes:

1. Don't emit "native" any more.

2. Add import of mscorlib to the start of every output file.

Change access to errorHdrHook back into a foreign label (this is now
supported by the NCG, or should be, and in any case, we don't build
HSstd with the NCG).

Remove addrOf_ErrorHdrHook, as the NCG now can (or should) cope with
foreign labels, and in any case, we don't use the NCG to build the
standard library.

The motivation for this fix is preventing HSstd_cbits depending on the
RTS, so that it can be built as a DLL (for .NET) without needing to
get the RTS built as a DLL (that way lies madness).

Append final newline to _stub.{c,h} output

Prev commit which tried to get rid of the 'ineffective CPP'
stage broke an invariant/assumption made by DriverPipeline.genPipeline,
I'm afraid.

The invariant being that from the input filename to a compilation
pipeline, the start stage/phase can be uniquely determined
(via DriverPhases.startPhase). run_phase no longer guarantees
this, its result filename may now be equal to the input filename.
[This resulted in -M not working properly when -cpp wasn't also used].

Patch this up by having the input filename to a compilation pipeline
stage be tagged with the assumed suffix of the output. This is
really just papering over the cracks, the proper way to tidy this
up is to avoid having to do the two-stage compilation pipeline in
Main.main.compileFile, i.e., reconsider how OPTIONS pragmas are
handled. I decided not to try to do this now for fear of destabilising
HEAD even further.

runSomething: don't export it

run_phase: added tysig

Replace GhcLibToolsHcOpts with FptoolsHcOpts, and make it apply to all
programs in fptools, not just the hslibs tools. Now there's a way of
controlling compiler flags to all programs in the tree, so

a) by default all utilities should be optimised (before this was only done
for one or two like hsc2hs)

b) if you're doing development work, you can get everything built quicker by
setting FptoolsHcOpts appropriately

Don't add -O here; should be up to the user

Make ghc-pkg find its path on Windows

Fix spacing bogon.

Rewrite getExecDir to use GetModuleFileName on Windows (thanks, sof),
and switch unDosifyPath's definitions between Windows and Unix so that
it actually does something on Windows.

Do away with that 'ineffective CPP' malarkey. run_phase now returns
the FilePath of its output file; in the event CPP isn't required,
we then just return the input file. (The extra LINE pragma that
the 'ineffective CPP' inserted was a NOP).

Appears to speed things up a bit; mingw/Win32 builds no longer need to
do a slow copyFile operation - other plats are saved from doing a
System.system call.

BTW, there's an opportunity to shorten the critical path for .hs files
some in the driver: at the moment 'unlit' is run over all input.

Avoid needless redefn of HAVE_ALLOCA

Add win32 package for Windows ghc.

Rewrite getExecDir with Win32Registry calls. Duh.

Two bug-fixes to the new newtype story

1. 	Be consistent about using TcType (not Type) in the
	typechecker.  There was an odd function in TcMType that
	used splitTyConApp instead of tcSplitTyConApp, which
	resulted in bogus error messages

2.	TcType.isTauTy should not look through SourceTy

Make getExecDir work on Windows by reading the registry

ie -> i.e.

Fix jade detection on Windows for jades that don't understand Unix paths

Hmm..are the Cambridge offices running low on oxygen? Desloppified to make stage2 work again

Undo prev. commit, it was just plain wrong

-- 'hybrid' support for DOS-style paths in directory lists.
--
-- That is, if "foo:bar:baz" is used, this interpreted as
-- consisting of three entries, 'foo', 'bar', 'baz'.
-- However, with "c:/foo:c:\\foo;x:/bar", this is interpreted
-- as four elts, "c:/foo", "c:\\foo", "x", and "/bar" --
-- *provided* c:/foo exists and x:/bar doesn't.
--
-- Notice that no attempt is made to fully replace the 'standard'
-- split marker ':' with the Windows / DOS one, ';'. The reason being
-- that this will cause too much breakage for users & ':' will
-- work fine even with DOS paths, if you're not insisting on being silly.
-- So, use either.

get rid off gcc warning

Zap another ghc_411_at_least.

Change the test for whether to include GHCi support in the compiler to
be closer to "are we bootstrapping with the same compiler".

oops: I changed the names of some of the GC stubs, and didn't realise they
were mentioned here too.

getTimes: fix Win95 fallback

Fix path for Windows jade

Add test for broken takeMVar/putMVar in 5.00.2.

Bug reported by Greg Mildenhall <gregm@pc-121.cs.uwa.edu.au> on
comp.lang.functional..

lib/gcc-lib -> gcc-lib

Fix a couple of nasty bugs in the take/putMVar implementation.

Now we keep the invariant that a full MVar only has blocked putMVars
on its queue, and an empty MVar only has blocked takeMVars on its
queue.  It was the absence of this invariant that led to accidental
deadlock before.

The second bug is that there was a window between a blocked thread
being restarted and it actually retrying the takeMVar/putMVar
operation when it could receive an exception, which would also lead to
deadlock.

The solution to both these problems (as suggested by Simon P.J.) is to
atomically wake up and perform the next blocked putMVar when we do a
take, and vice versa.  As a side effect, takeMVar & putMVar should be
much faster when blocking & restarting, because we now shortcut the
retrying of the blocked operation and we use a more specialised stack
layout for the blocked thread.  Unfortunately, things got more
complicated too, but there are comments explaining what's going on.

fix eqType bug

New version for GHC 5

Final stage of the PACKAGE oopsathon, or else...

Changes to nuke RAWCPP.