GitLab

They should use the GHC from the build tree, not the bootstrapping compiler.

  
The renamer wasn't attaching the right used-variables to a
TransformStmt constructor.

The real modification is in RnExpr; the rest is just
pretty-printing and white space.

See Note [Case elimination: lifted case].
Thanks to Roman for identifying this case.

If GHC's command line options are bad then the options parser uses the
pretty printer before the -dppr-cols flag has been read.

 -dsuppress-all
 -dsuppress-type-applications
 -dsuppress-idinfo

This is a temporary measure until we fix the bug properly (which is
somewhat tricky, and we think might be easier in the new code
generator).

For now we get:

ghc-stage2: sorry! (unimplemented feature or known bug)
  (GHC version 7.1 for i386-unknown-linux):
        Trying to allocate more than 1040384 bytes.

See: http://hackage.haskell.org/trac/ghc/ticket/4550
Suggestion: read data from a file instead of having large static data
structures in the code.

-		"sorry! (this is work in progress)\n"
+		"sorry! (unimplemented feature or known bug)\n"

Added support for settings [args, prog, prompt, editor and stop].
Now :unset supports the same set of options as :set.

Also added a few comments, and a load of code got indented 1 level deeper.

Fixes for #4512: EventLog.c - provides ability to terminate event logging, Schedule.c - uses them in forkProcess.

This fixes the "does unsetenv return void" test in the unix package on
OS X, if I tell it to make 10.4-compatible binaries. The test uses
CPPFLAGS but not CFLAGS, so it thought it returned int (as it was
in 10.5-mode), but the C compiler (using CFLAGS, so in 10.4 mode)
thought it returned void.

I also added CONF_LD_OPTS_STAGE$3 to the list of things in LDFLAGS,
which looks like an accidental ommission.

I don't remember why we made it use gcc instead, but going back to
using ghc doesn't seem to break anything, and should fix the build
on OS X 10.6.

But only when the module exports refer to different modules.
See ticket #4478.

I suspect this is a vary rarely used extension to the official layout
rule.

I really don't know how this module got left out of my last
patch, namely
  Thu Dec  2 12:35:47 GMT 2010  simonpj@microsoft.com
  * Re-jig simplifySuperClass (again)

I suggest you don't pull either the patch above, or this
one, unless you really have to.  I'm not fully confident
that it works properly yet.  Ran out of time. Sigh.