GitLab

slow mode is 14% slower than normal. It uses -DDEBUG for the stage 2
compiler, and -XGenerics for the stage 2 compiler and the libraries.
I believe that most of the slowdown is actually caused by -XGenerics
rather than -DDEBUG.

Yurgh. See Note [Desugaring seq (3)]

Currently it causes a load of ghci-debugger tests to fail and takes
63% longer.

This patch collects several related things together.

* Refactor TcDeriv so that the InstInfo and the method bindings are renamed
  together.  This was messy before, and is cleaner now.  Fixes a bug caused 
  by interaction between the "auxiliary bindings" (which were given 
  Original names before), and stand-alone deriving (which meant that those
  Original names came from a different module). Now the names are purely
  local an ordinary.

  To do this, InstInfo is parameterised like much else HsSyn stuff.

* Improve the location info in a dfun, which in turn improves location 
  info for error messages, e.g. overlapping instances

* Make sure that newtype-deriving isn't used for Typeable1 and friends.
  (Typeable was rightly taken care of, but not Typeable1,2, etc.)

* Check for data types in deriving Data, so that you can't do, say,
 	deriving instance Data (IO a)

* Decorate the derived binding with location info from the *instance* 
  rather than from the *tycon*.  Again, this really only matters with
  standalone deriving, but it makes a huge difference there.

I think that's it.  Quite a few error messages change slightly.

If we release 6.8.4, this should go in if possible.

Avoids conflicts with the Cabal library on case-insensitive filesystems

When building ghc-prim/Setup we weren't putting the hi files in the
right place.

This means that we don't have to make a Setup program for each library
individually, and also simplifies the build system a bit.

We were inconsistent about whether to use the name "MutArr#" or
"MutableArray#". Likewise ByteArr#/ByteArray# and
MutByteArr#/MutableByteArray#.

It leads to annoying rebuilding when working in a built tree.
We'll handle this differently for 6.10.

Many of the character types were wrong. Now the asc* names really do mean
ASCII, rather than latin-1.