A very important invariant of the simplifier is that we do not simplify
an arbitrarily large expression more than once in a single pass. If this
can happen, then we can get exponential behaviour, when the large expression
itself has a large sub-expression which is simplified twice, and so on.

GHC has a long-standing bug which allows this repeated simplification to 
happen.  It shows up when we have a function like this

	f d BIG
where f's unfolding looks like
	\x -> case x of (a,b) -> a
Of course this is v common for overloaded functions.

Before this patch we simplified all the args (d and BIG) before
deciding to unfold f.  Then we push back the simplified BIG onto the
continuation stack, inline f, so now we have
	(case d of (a,b) -> a) BIG
After we reduce the case a bit, we'll simplify BIG a second time.  And
that's the problem.

The quick-and-dirty solution is to keep a flag in the ApplyTo continuation
to say whather the arg has already been simplified.  An alternative would
be to simplify it when first encountered, but that's a bigger change.

This looks to me like a long-standing bug. simplNonRecX was calling
preInlineUnconditionally, even though it was given an already-simplified
expression.  Exponential behaviour beckons.

I'm being more paranoid about repeatedly simplifying things (to avoid
exponential behaviour.)  postInlineUnconditionally looks as if it
could repeated simplify the same expression; this patch stops it doing
so.

The extra lines are all comments!

This terrible bug in tcLHsConTy is pretty much guaranteed to show up
on an program involving a GADT with more than one type parameter.

This bug isn't present in the STABLE branch.

Manuel: it is *not* necesary to merge this patch into the FC branch; 
just ignore it.

This fixes building the compiler with -prof in $(GhcStage1HcOpts)

See #805.  This was here to catch bugs that resulted in an infinite
number of worker threads being created.  However, we can't put a
reasonable bound on the number of worker threads, because legitimate
programs may need to create large numbers of (probably blocked) worker
threads.  Furthermore, the OS probably has a bound on the number of
threads that a process can create in any case.

See #815

See #753

Actually this patch fixes two errors. one was a trivial typo in 
tha last patch (b_ty should be b_tau), which led to an infinite loop
when compiling Data.Generic.Twins.  

Fixing that revealed a more serious error in the same function.
I was sloppy about dealing robsutly with name-capture for nested
quantifiers in pre-subsumption and pre-matching; and sure enough
I got bitten.  Sigh.  I think it is right now.

A lazy pattern match must be for a lifted type. This is illegal:

	f x = case g x of 
                ~(# x,y #) -> ...

This commit fixes the problem.  Trac #845, test is tcfail159
 

srcSpanStartLine/srcSpanEndLine panic on UnhelpfulLoc. They should not
really be exported by SrcLoc at all, but unfortunately they are used in
Lexer.x, which knows enough to avoid the panic.

However the call in RnEnv didn't know, and the panic was triggered 
by Template Haskell spliced code.  This patch fixes it by exporting
the predicate RnEnv wanted, namely isOneLineSpan.

See: http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html

Just because we can and because every other compiler does,
lets stick in an identifier directive: .ident "GHC x.y.z"
into the assembly output of the NCG.

On recent GNU ELF systems one can mark an object file as not
requiring an executable stack. If all objects- linked into a
program have this note then the program will not use an executable
stack, which is good for security (and some distros have it as a
QA policy). GHC generated code does not need an executable stack
so add the note to the assembly output of the native code
generator (conditional on a configure test).

previously hsc2hs just exits with a non-zero exit code, now if any of
the compilation, linking or runing phases fail then we get a message
saying so and the failing command is printed.

Patch mostly from Lennart Augustsson in #803, with additions to
Task.c by me.

The pre-subsuption and pre-matching functions should NEVER make bogus
bindings of type variables, although they are free to bale out and make
too few bindings.

I hadn't been thiking carefully enough about this, and there were two
separate bugs.  

- Firstly, in pre-subsumption we must ignore the 'theta'
  part of any overloaded type.  

- Second, in pre-matching, we must return the empty subustition 
  on a mis-match, rather than returning the substitution so far.

This bug showed up when compiling Data.Generics.Schemes.hs, and is
imortalised in test tc206

Improve a little-used error message.  Given
	f :: a -> a
	f x y = e
the error says 

	The equations for f have two arguments
	but its type `a -> a' has only one

(Before, it said "its type `a' has only one" which is bogus.

prof_file was being fclose'd in both gen_XML_logfile and hs_exit, leading
to glibc complaining of a double free.