GitLab

In particular, if we're searching for the profiling version of a
module in another package, then suggest that perhaps it might not have
been installed.

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.