GitLab

now that cross-package deps are tracked correctly.

In particular, this means ghc gets built with -rtsopt, -threaded, etc again.

We can now rely on cross-package deps working properly, as we require
GHC 6.12.

We no longer use dummy-ghc; instead we don't configure most packages
until the stage1 compiler is available.
  
We also now use Cabal for building the ghc-bin package.

There are a couple more sanity checks too.

Fixes a rare race when both libHSffi.a and libHSffi_p.a were being built
at the same time:

"cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a
"cp" libffi/dist-install/build/libffi.a libffi/dist-install/build/libHSffi.a
"cp" libffi/dist-install/build/libffi.so libffi/dist-install/build/libHSffi-ghc7.1.20110115.so
cp: cannot create regular file `libffi/dist-install/build/libHSffi.a': File exists

Johan discovered that when INLINABLE things are specialised
bad things can happen. This patch implements a hack -- but
it's a simple hack and it solves the problem.

See Note [Inline specialisations]. 

The hack part is that really INLINABLE should not cause *any* loss
optimisation, and it does; see Note [Don't w/w INLINABLE things] in
WorkWrap.

Under obscure circumstances (actually only shown up when fixing something
else) it was possible for a variable binding to be discarded although
it was still used.  See Note [Top level and postInlineUnconditionally]

This is a recently-introduce function, which was returning
a [Name], being the names of the dfuns.  But what you really
want (obviously!) is the ClassInstances, and we have a TH type
for that.

This is an API change, so don't merge into GHC 7.0.  But it's
a new part of TH which is still settling down.

Fixes Trac #4863.

I'd done all the work to add fuzzy-match suggestions, but they
weren't really being used!  Here's what you get now

   module Foo where
    import Data.Lst

Foo.hs:3:1:
    Failed to load interface for `Data.Lst'
    Perhaps you meant
      Data.List (from base)
      Data.List (needs flag -package haskell2010-1.0.0.0)
      Data.Int (needs flag -package haskell2010-1.0.0.0)
    Use -v to see a list of the files searched for.

Fixes Trac #4877.

Patch supplied by the bug reporter, tidied up by me.

$ ./configure --with-ghc=$HOME/fp/bin/i386-unknown-linux/ghc --build=x86_64-unknown-linux
checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC version date... inferred 7.1.20110107
checking version of ghc... 7.0.1
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
Host platform inferred as: i386-unknown-linux
Target platform inferred as: i386-unknown-linux
This GHC (/home/simonmar/fp/bin/i386-unknown-linux/ghc) does not generate code for the build platform
   GHC target platform    : i386-unknown-linux
   Desired build platform : x86_64-unknown-linux

This patch embodies many, many changes to the contraint solver, which
make it simpler, more robust, and more beautiful.  But it has taken
me ages to get right. The forcing issue was some obscure programs
involving recursive dictionaries, but these eventually led to a
massive refactoring sweep.

Main changes are:
 * No more "frozen errors" in the monad.  Instead "insoluble
   constraints" are now part of the WantedConstraints type.

 * The WantedConstraint type is a product of bags, instead of (as
   before) a bag of sums.  This eliminates a good deal of tagging and
   untagging.

 * This same WantedConstraints data type is used
     - As the way that constraints are gathered
     - As a field of an implication constraint
     - As both argument and result of solveWanted
     - As the argument to reportUnsolved

 * We do not generate any evidence for Derived constraints. They are
   purely there to allow "impovement" by unifying unification
   variables.

 * In consequence, nothing is ever *rewritten* by a Derived
   constraint.  This removes, by construction, all the horrible
   potential recursive-dictionary loops that were making us tear our
   hair out.  No more isGoodRecEv search either. Hurrah!

 * We add the superclass Derived constraints during canonicalisation,
   after checking for duplicates.  So fewer superclass constraints
   are generated than before.

 * Skolem tc-tyvars no longer carry SkolemInfo.  Instead, the
   SkolemInfo lives in the GivenLoc of the Implication, where it
   can be tidied, zonked, and substituted nicely.  This alone is
   a major improvement.

 * Tidying is improved, so that we tend to get t1, t2, t3, rather
   than t1, t11, t111, etc

   Moreover, unification variables are always printed with a digit
   (thus a0, a1, etc), so that plain 'a' is available for a skolem
   arising from a type signature etc. In this way,
     (a) We quietly say which variables are unification variables,
         for those who know and care
     (b) Types tend to get printed as the user expects.  If he writes
             f :: a -> a
             f = ...blah...
         then types involving 'a' get printed with 'a', rather than
         some tidied variant.

 * There are significant improvements in error messages, notably
   in the "Cannot deduce X from Y" messages.

This patch fixes Trac #4875.  The main point is to do dependency
analysis on type and class declarations, and kind-check them in
dependency order, so as to improve error messages.

This patch means that a few programs that would typecheck before won't
typecheck any more; but before we were (naughtily) going beyond
Haskell 98 without any language-extension flags, and Trac #4875
convinces me that doing so is a Bad Idea.

Here's an example that won't typecheck any more
       data T a b = MkT (a b)
       type F k = T k Maybe

If you look at T on its own you'd default 'a' to kind *->*;
and then kind-checking would fail on F.

But GHC currently accepts this program beause it looks at
the *occurrences* of T.

For single-character identifiers we now don't make any suggestions
See comments in Util.fuzzyLookup

We need the unfolding even for a *recursive* function (indeed
that's the point) and I was using the wrong function to get it
(idUnfolding rather than realIdUnfolding).

They're a little nicer now, and a regression in the cygwin build is
fixed (the $i in the destination wasn't surviving being passed through
cygpath).

As far as I can tell, it is the responsibility of the program to save
and restore its own terminal settings across a suspend/foreground, the
shell doesn't do it (which seems odd).  So I've added a signal handler
for SIGTSTP to the RTS which will save and restore the terminal
settings iff we modified them with hSetBuffering or hSetEcho (we
already restore them at exit time in these cases).

cygwin's /bin/install doesn't set file modes correctly if the
destination path is a C: style path:

$ /bin/install -c -m 644 foo /cygdrive/c/cygwin/home/ian/foo2
$ /bin/install -c -m 644 foo c:/cygwin/home/ian/foo3
$ ls -l foo*
-rw-r--r-- 1 ian None 0 2011-01-06 18:28 foo
-rw-r--r-- 1 ian None 0 2011-01-06 18:29 foo2
-rwxrwxrwx 1 ian None 0 2011-01-06 18:29 foo3

This causes problems for bindisttest/checkBinaries.sh which then
thinks that e.g. the userguide HTML files are binaries.

We therefore use a /cygdrive path if we are on cygwin