GitLab

usrbincc authored May 20, 2013 and ian@well-typed.com committed Jun 04, 2013

- Remove unused property `def_prompt`.

Make expands things even in comments

The LLVM back end does not yet work when building dynamically.

kgardas authored Apr 04, 2013 and ian@well-typed.com committed May 30, 2013

This patch disables shared libs support on arm-unknown-linux platform. It
unbreaks ghc-stage2 on this platform after recent Ian's changes
in dynamic/shared libs domain. The reason why ghc-stage2 fails when linked
with shared libs is still unknown so this is just a workaround at the moment,
but it at least recovers previous "correct" behavior of ghc-stage2
on ARM/Linux

where the invariant didn't hold, leading to
subsequent chaos. Happily an ASSERT caught it.

Somtimes we need (xs ++ ys) in situations where ys is
almost always empty.  Utils.chkAppend checks for that
case first.

Should help to track down cache-out-of-date problems

The details of this are described in Note [magicSingIId magic] in basicTypes/MkId.lhs

This long-overdue fix arranges to eta-reduce the axiom for a
data/newtype instance in the same way that we have longq
eta-reduced the axiom for a newtype.

See Note [Eta reduction for data family axioms] in TcInstDcls
and Note [Deriving, type families, and partial applications] in TcDeriv.

Fixes Trac #7809

Finally (I hope) fixes Trac #7903.

See Note [Zonking inside the knot] in TcHsSyn

See Note [Type determines value] in Specialise.

This is a long-standing regression (Trac #7797), which meant that in
particular the Eq [Char] instance does not get specialised.
(The *methods* do, but the dictionary itself doesn't.)  So when you
call a function
     f :: Eq a => blah
on a string type (ie a=[Char]), 7.6 passes a dictionary of un-specialised
methods.

This only matters when calling an overloaded function from a
specialised context, but that does matter in some programs.  I
remember (though I cannot find the details) that Nick Frisby discovered
this to be the source of some pretty solid performanc regresisons.

Anyway it works now. The key change is that a DFunUnfolding now takes
a form that is both simpler than before (the DFunArg type is eliminated)
and more general:

data Unfolding
  = ...
  | DFunUnfolding {     -- The Unfolding of a DFunId
    			-- See Note [DFun unfoldings]
      		  	--     df = /\a1..am. \d1..dn. MkD t1 .. tk
                        --                                 (op1 a1..am d1..dn)
     		      	--     	    	      	       	   (op2 a1..am d1..dn)
        df_bndrs :: [Var],      -- The bound variables [a1..m],[d1..dn]
        df_con   :: DataCon,    -- The dictionary data constructor (never a newtype datacon)
        df_args  :: [CoreExpr]  -- Args of the data con: types, superclasses and methods,
    }                           -- in positional order

That in turn allowed me to re-enable the DFunUnfolding specialisation in
DsBinds.  Lots of details here in TcInstDcls:
	  Note [SPECIALISE instance pragmas]

I also did some refactoring, in particular to pass the InScopeSet to
exprIsConApp_maybe (which in turn means it has to go to a RuleFun).

NB: Interface file format has changed!

This fixes Trac #7937

This makes the output of :info more useful

Otherwise we get errors for polykinded type families;
   type family F a :: *
Then :k F
would give an ambiguity check trying to unify (F k1) with (F k2),
which is all a bit stupid.

I found this when investigating Trac #7939

It doesn't work

This reverts commit 5734f7af.

It didn't fully fix -dynamic-too on Windows

See comments for details.