Sun Oct 28 06:45:34 PDT 2007  Ian Lynagh <igloo@earth.li>

Sun Oct 28 05:35:52 PDT 2007  Ian Lynagh <igloo@earth.li>

Mostly this patch is refacoring, but it also avoids post-tc zonking if
the typechecker found errors.  This is good because otherwise with
DEBUG you can get the "Inventing strangely-kinded TyCon" warning.

The type checker was only reporting the first message if an equality
failed to match.  This patch does a bit of refactoring and fixes the
bug, which was in the bogus use of eqInstMisMatch 
in tcSimplify.report_no_instances.b

This is really a bug in 6.8 too, so this would be good to merge across
to the 6.8 branch.

This patch renames the DOC_OPTIONS pragma to OPTIONS_HADDOCK. It also
adds "-- # ..."-style Haddock option pragmas, for compatibility with
code that use them.

Another change is that both of these two pragmas behave like
OPTIONS_GHC, i.e. they are only allowed at the top of the module, they
are ignored everywhere else and they are stored in the dynflags. There is
no longer any Haddock options in HsSyn.

Please merge this to the 6.8.2 branch when 6.8.1 is out, if appropriate.

Don't re-add the worker info to a binder until completeBind. It's not
needed in its own RHS, and it may be replaced, via the substitution
following postInlineUnconditionally.

(Fixes build of the stage2 compiler which fell over when Coercion.lhs
was being compiled.)

	Merge to STABLE please

Liberate case was being far too gung-ho about what to specialise. This
bug only showed up when a recursive function 'f' has a nested recursive
function 'g', where 'g' calls 'f' (as well as recursively calling 'g').
This exact situation happens in GHC/IO.writeLines.

This patch puts things right; see Note [When to specialise].  Result:
much less code bloat.

Please push to stable branch

Simon

In a pattern binding with a pattern type signature, such as

	(Just (x::a)) = e

the pattern type signature cannot bind type variables.  Hence
'a' must be in scope already for the above example to be legal.

This has been the situation for some time, but Dan changed it when
adding view patterns.  This one-line change restores the old behaviour.

	(Merge to 6.8 branch after testing.)

There were a number of delicate interactions between RULEs and inlining
in GHC 6.6.  I've wanted to fix this for a long time, and some perf
problems in the 6.8 release candidate finally forced me over the edge!

The issues are documented extensively in OccurAnal, Note [Loop breaking
and RULES], and I won't duplicate them here.  (Many of the extra lines in
OccurAnal are comments!)

This patch resolves Trac bugs #1709, #1794, #1763, I believe.

This is a hack, but it means we get libHSrts*.a etc rather than just
libHSrts.a.

	(Please merge this, and the preceding 
	handful from me to the 6.8 branch.)

This patch fixes a serious problem in the type checker, whereby
TcSimplify was going into a loop because it thought improvement
had taken place, but actually the unificataion was actually deferred.

We thereby fix Trac #1781, #1783, #1795, and #1797!

In fixing this I found what a mess TcSimplify.reduceContext is! 
We need to fix this.

The main idea is to replace the "improvement flag" in Avails with
a simpler and more direct test: have any of the mutable type variables
in the (zonked) 'given' or 'irred' constraints been filled in?
This test uses the new function TcMType.isFilledMetaTyVar; the test
itself is towards the end of reduceContext.

I fixed a variety of other infelicities too, and left some ToDos.

An AbsBinds abstrats over evidence, and the evidence can be both
Dicts (class constraints, implicit parameters) and EqInsts (equality
constraints).  So we need to
  - use varType rather than idType
  - use instToVar rather than instToId
  - use zonkDictBndr rather than zonkIdBndr in zonking

It actually all worked before, but gave warnings.

  compileToCore returned just a list of CoreBind, which isn't enough,
since to do anything with the resulting Core code, you probably also
want the type declarations. I left compileToCore as it is, but added a
function compileToCoreModule that returns a complete Core module (with
module name, type environment, and bindings). I'm not sure that
returning the type environment is the best way to represent the type
declarations for the given module, but I don't want to reinvent the
External Core wheel for this.