GitLab

* Fix a bug that led to a crash with
    data family T a
    deriving Functor T

* Allow deriving Typeable for data families
    data family T a
    deriving Typeable1 T

* Some refactoring and tidying

This (annoyingly) requires us to re-flatten the class predicate.
See Note [Flattening in error message generation]

This fixes Trac #4494.  See Note [Extra TcsTv untouchables] in TcSimplify.

They said:
    (NOTE: not supported since GHC 4.x.  Please ask if you're interested
    in this.)

In TcBinds we want to use isAnyInlinePragma, to get
both INLINE and INLINABLE.  I don't know why this isn't
leading to failures for others!  The (bogus) error I got, 
triggered by this bug was:

  libraries\haskeline\System\Console\Haskeline\Key.hs:23:1:
    You cannot SPECIALISE `M.findWithDefault'
      because its definition has no INLINE/INLINABLE pragma

A simple refactoring in the parser

Regression testing and user feedback for GHC 7.0 taught
us a lot.  This patch fixes numerous small bugs, and some
major ones (eg Trac #4484, #4492), and improves type
error messages.

The main changes are:

* Entirely remove the "skolem equivalance class" stuff;
  a very useful simplification

* Instead, when flattening "wanted" constraints we generate
  unification variables (not flatten-skolems) for the
  flattened type function application

* We then need a fixup pass at the end, TcSimplify.solveCTyFunEqs,
  which resolves any residual equalities of form
      F xi ~ alpha

* When we come across a definite failure (e.g. Int ~ [a]),
  we now defer reporting the error until the end, in case we
  learn more about 'a'.  That is particularly important for
  occurs-check errors.  These are called "frozen" type errors.

* Other improvements in error message generation.

* Better tracing messages

This is just a backward-compatibility thing, to be removed
eventually.

showMultiLineString is only in >= 7.1.

as well as decommiting it.

In particular, instead of
   Cannot match 'a' with 'b'
we get
   Could not deduce (a~b) from context (F a ~ b)
or whatever

I'm surprised that these haven't caused any problems (or maybe they have?)

We were generating PrimopWrappers.hs twice in two different places,
one for the normal build and one for Haddock (I think).  Unfortunately
one of these was causing extra rebuilding, because the file dropped
into the dist-install/build/autogen directory, where it was picked up
by the automatic HS_SRCS detection in subsequent make runs.  This was
exposed by a recent change to HS_SRCS:

  Wed Oct 20 11:47:59 BST 2010  Ian Lynagh <igloo@earth.li>
    * Look for sources in Cabal's autogen directory too

This should fix the stage3 failures in the build bots.

It now says:

ghc-stage2: sorry! (this is work in progress)
  (GHC version 7.1.20101028 for i386-apple-darwin):
	Vectorise.Builtins.indexBuiltin
    
    DPH builtin function 'sumTyCon' of size '11' is not yet implemented.
    This function does not appear in your source program, but it is needed
    to compile your code in the backend. This is a known, current limitation
    of DPH. If you want it to to work you should send mail to cvs-ghc@haskell.org
    and ask what you can do to help (it might involve some GHC hacking).


I added 'pprSorry' that behaves like 'pprPanic' except it say sorry! instead 
of panic!, and doesn't ask the user to report a bug.