Fixes signals004(threaded1,threaded2) on OS X 32.

Fixes T3807 on OS X 32.

Simon Marlow authored 12 years ago and ian@well-typed.com committed 12 years ago

Submitted by: Markus Pfeiffer <markus.pfeiffer@morphism.de> on cvs-ghc

This bug was making GHC loop when printing external core from test T7239.

Apparently this fixes the build with dblatex 0.3.4.

This fixes Trac #7503.

This fixes Trac #7368. The problem was that we were matching
   Bad w ~ f (Bad f)
where (f :: * -> *).  Thta leads to (w ~ Bad f), which is
ill-kinded, but matchExpectedTyConApp was returning the (Bad f)
as the argument type, and that was being used to instanatiate
w in the data constructor type, which is very bad.

The code also becomes simpler and easier to understand, which is
an excellent thing.

This reverts commit 5ea49271.

jpm@cs.ox.ac.uk authored 12 years ago and ian@well-typed.com committed 12 years ago

Signed-off-by: Jose Pedro Magalhaes <jpm@cs.ox.ac.uk>

    commit f184d9ca
    Author: Simon Marlow <marlowsd@gmail.com>
    Date:   Mon Dec 10 12:00:54 2012 +0000

    Fix a bug in the handling of nested orElse

    Exposed by the following snippet, courtesy of Bas van Dijk and Patrick
    Palka on libraries@haskell.org:

    import Control.Concurrent.STM
    main = do
      x <- atomically $ do
             t <- newTVar 1
             writeTVar t 2
             ((readTVar t >> retry) `orElse` return ()) `orElse` return ()
             readTVar t
      print x

Without -O, we previously tried to make interface files smaller
by not including the data constructors of data types.  But
there are a lot of exceptions, notably when Template Haskell is
involved or, more recently, DataKinds.

However Trac #7445 shows that even without TemplateHaskell, using
the Data class and invoking Language.Haskell.TH.Quote.dataToExpQ
is enough to require us to expose the data constructors.

So I've given up on this "optimisation" -- it's probably not
important anyway.  Now I'm simply not attempting to trim off
the data constructors.  The gain in simplicity is worth the
modest cost in interface file growth, which is limited to the
bits reqd to describe those data constructors.

Conflicts:
	compiler/main/TidyPgm.lhs

Thanks to Richard Eisenberg for writing this.

This reverts the change in Trac #7347, which prevented promotion
of existential data constructors.  Ones with constraints in
their types, or kind polymorphism, still can't be promoted.

This patch fixes a quite egregious bug. runTcS was intialising
the 'untouchables' to NoUntouchables, which is quite wrong for
the invocation in TcSimplify.simplifyInfer.  Result: missed
skolem-escape check and seg-fault city.

All this is done differently, and better, in HEAD, so this
patch is needed only on the branch.

This is a kludge, and means that ghc/haddock won't be able to use
more than 2G of RAM. But it'll make sure that ghci works in the short
term while we work on a proper fix.

Trac #7410 pointed out a terrible error message, which is
much improved by this patch.

Conflicts:
	compiler/typecheck/TcHsType.lhs

Fixes Trac #7451. See Note [Kind Constraint and kind *] in Kind.lhs.

Conflicts:
	compiler/types/Kind.lhs
	compiler/types/Type.lhs

I don't konw how this was left out before; Trac #7347.

In fixing this I did the usual round of refactoring.  In particular, I
cached the fact that a DataCon can be promoted in the DataCon
itself (the dcPromoted field).

    commit 2c207b6f

    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Tue Oct 2 18:11:08 2012 +0100

    Compare the kinds of type variables when comparing types

    This is just a bug that's been around since we introduced
    polymorphic kinds.  The roots are in Type.cmpTypeX, but
    there was a variant in TcRnDriver.checkBootTyCon, which
    is where it came up.

    Fixes Trac #7272