Changes to ghc(7)

Changes to ghc:
commit 7f467d0fbb1424f638a0d39caf57b9c0198421a8
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Wed Jun 11 20:54:58 2014 +0100

    Fix Windows build (wibble to fix for Trac #4934)

commit 7d9feb264a4fc3c15d1e5f88f2e7a04202ed9743
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Wed Jun 11 19:53:06 2014 +0100

    Fix a serious, but rare, strictness analyser bug (Trac #9128)

    In a special case for trivial RHSs (see DmdAnal.unpackTrivial),
    I'd forgotten to include a demand for the RHS itself.
    See Note [Remember to demand the function itself].

    Thanks to David Terei for guiding me to the bug,
    at PLDI in Edinburgh.

commit c8295c0bd58485db5572d3c35427d321bdf1b7d0
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Wed Jun 11 19:49:50 2014 +0100

    Simplify variable naming in tcDataKindSig

    Now that we are very consistent about tidying when converting
    to IfaceSyn, we don't need to worry about accidental capture
    of the "extra" type variables in tcDataKindSig.  (Previously
    we gave them weird names like $a.)

    However, it is nicer for the user if we don't gratuitously
    re-use an in-scope name, so we take care not to do that
    .

commit e5257f8fe20f5278c23693f1523e298e6fdaa064
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Wed Jun 11 15:09:55 2014 +0100

    Fix tyConToIfaceDecl (Trac #9190)

    There are three bugs here, one serious

     * We were failing to tidy the type arguments in an IfTyConParent
       This is what was causing Trac #9190.

     * toIfaceTcArgs is careful to suppress kind arguments, but there
       was a clone, tidyToIfaceTcArgs in IfaceSyn which didn't.
       Now the latter goes via the former.

     * When pretty-printing a IfaceDecl for an algebraic data type, and
       doing so in Haskell-98 syntax, we were silently assuming that the
       universal type variables of the TyCon and the DataCon were the
       same. But that has not been true for some time. Result: a very
       confusing display.

       Solution: during the conversion to IfaceSyn, take the opportunity
       to make the universal type variables line up exactly.  This is very
       easy to do, makes the pretty-printing easy, and leaves open the future
       possiblity of not serialising the universal type variables of the
       data constructor.

commit 748bec483b8e1c8ae69e68903f5c3d5bd93e92be
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Tue Jun 10 17:57:49 2014 +0100

    White space only

commit 7817ec16d186a59f169202c930e211bda553777b
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Tue Jun 10 17:57:37 2014 +0100

    Comments only explaining the imports for GHC.Integer, GHC.Tuple

    See Note [Depend on GHC.Integer]
        Note [Depend on GHC.Tuple]

    This came up when Joachim got an unexpected missing-dependency
    error when fiddling with Data.Coerce.

commit 56f8777f99d9fd849ca6f1151fead3f62707f308
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Tue Jun 10 17:50:22 2014 +0100

    Improve error message in Trac #8883

    The improvement is to report the inferred type in the error message,
    as suggested in email on ghc-deves (10 Jun 14).