GitLab

- mkDataConIds forced an algebraic worker/wrapper on newtype instances (not
  on vanilla newtypes).  I am not sure where this came from (from code I
  wrote or from the recent restructuring of MkIds), but its not the right
  thing to do.  In particular, it requires newtype instances to have con_info
  labels in the generated code, which makes no sense.
- Worker construction for newtypes is smart enough that it will construct the
  right signature for newtype instances (ie, one that mentions the family
  type constructor, not the instance tycon).

- Fix typo introduced when moving deriving-specific code from TcEnv to TcDeriv
- Thanks to Roman for the bug report

This patch implements the suggestion in Trac #1398.  It's obviously
stupid to suggest -fno-monomorphism-restriction if the user is already
using it.  

(Maybe another suggestion would be good, but this one clearly bogus.)

The renamer used to be responsible for making sure that all interfaces
with instance decls (other than orphans) were loaded.  But TH makes that
impossible, so the typechecker does it, via checkWiredInTyCon.

This patch simply removes redundant additions to the free-variable set
in the renamer, which were there, I believe, solely to ensure that the 
instances came in.  Removing them should change nothing, but it's a 
useful clean up.

Typechecking of explicit tuples is done "by hand" (rather than using
boxySplitTyConApp) so that rigidity is maintained.  In making that change
I'd forgotten to retain the call to checkWiredInTyCon, which is important
to make sure instances are brought into scope.

Test is tc227.

I skipped utils/hsc2hs/Main.hs since its ifs also involved
checking for old versions of nhc98 (I don't want to figure that out),
but removed everything else I found relating to building with pre-6.0

The old code didn't work on Mac OS X, as "which" returns successfully
when it can't find the program.

ghc still works, also the module was tested in hugs and ghc

Submitted by: Matthias Kilian <kili@outback.escape.de>

Can't check $(GhcUnregisterised) eagerly, because it might not have
been set yet (it's set in build.mk).

When I rejigged constraint simplification when inferring types, I missed
a corner case.  Somethign that it's distressingly easy to do.  Anyway
this fixes it; see the comments in tcSimplifyInfer with the second call
to partition and extendLIEs.

The test is tcfail181.

This used to be a parse error, but ! annotations are now handled
further downstream in the compiler, and I'd forgotten to check
that newtypes do not have strictness annotations.

The test read008 is technically in the wrong place (it's a typechecker
test now) but that doesn't matter

Currently, when the user invokes the GHCi editor without a parameter
GHCi chooses the last file that loaded _sucessfully_.
This patch changes this behavior to start the editor with the
last file that _faild_ (this being what I usually want to edit).
Caveat: we use the module graph to determine what happened
and so we do not catch errors that occured during dependecy
analysis (e.g., a mis-typed module name) but we could fix this later.

I reorganized the lexing of numeric literals a bit so the code didn't
get too ugly, after trying a few ways, and also considering possible plans
to be able to conditionally lex negative _boxed_ literals.

I decided against adding parseSignedInteger since octal
and hex literals often have junk between the '-' and the
digits, but, compare to Util.readRational which does handle
signed numbers.  Also since Integers - mathematically and
in Haskell - can be negative, normally.

It doesn't work yet, but I'm pretty sure that's because the bindist is
broken rather than the installer is broken.