GitLab

We weren't handling InBoth properly.  InBoth needs to be expanded to
appropriate InReg/InMem locations *before* building the interference
graph, otherwise an InBoth will not be seen to conflict with other
InReg/InMem locations.

This will let us express write barriers in C--

as a precautionary measure.  It is definitely required for GC.c,
but it may well become necessary for other files in the future due to
our (mis-)use of the C "type system".

In SpecConstr.scBind, we should pass the optimised body (body') to
specialise, not the un-optimised one. In this way we'll benefit from
specialising any nested functions inside body.

Discovered by Roman.

For some reason, SpecConstr wasn't taking account of let-bound constructors:
	let v = Just 4
	in ...(f v)...

Now it does.  An easy fix fortunately.

This patch arranges that derived instances use the same instance-decl
checking code as user-defined instances.  That gives greater consistency
in error messages.

Furthermore, the error description if this consistency check fails is now
much more explicit.  For example, drvfail003 now says
     Variable occurs more often in a constraint than in the instance head
       in the constraint: Show (v (v a))
     (Use -fallow-undecidable-instances to permit this)
     In the derived instance
       instance (Show (v (v a))) => Show (Square_ v w a)

Consider this example (provided by Roman)

	foo :: Int -> Maybe Int -> Int
	foo 0 (Just n) = n
	foo m (Just n) = foo (m-n) (Just n)

SpecConstr sees this fragment:

	case w_smT of wild_Xf [Just A] {
	  Data.Maybe.Nothing -> lvl_smf;
	  Data.Maybe.Just n_acT [Just S(L)] ->
	    case n_acT of wild1_ams [Just A] { GHC.Base.I# y_amr [Just L] ->
	    $wfoo_smW (GHC.Prim.-# ds_Xmb y_amr) wild_Xf
	    }};

and correctly generates the rule

	RULES: "SC:$wfoo1" [0] __forall {y_amr [Just L] :: GHC.Prim.Int#
					  sc_snn :: GHC.Prim.Int#}
	  $wfoo_smW sc_snn (Data.Maybe.Just @ GHC.Base.Int (GHC.Base.I# y_amr))
	  = $s$wfoo_sno y_amr sc_snn ;]

BUT we must ensure that this rule matches in the original function!
Note that the call to $wfoo is
	    $wfoo_smW (GHC.Prim.-# ds_Xmb y_amr) wild_Xf

During matching we expand wild_Xf to (Just n_acT).  But then we must also
expand n_acT to (I# y_amr).  And we can only do that if we look up n_acT
in the in-scope set, because in wild_Xf's unfolding it won't have an unfolding
at all. 

Happily, fixing the bug is easy: add a call to 'lookupRnInScope' in the 
(Var v2) case of 'match'.

Happy, Alex and Haddock are built separately using Cabal now.

When the Specialise pass generates a specialised copy of a function,
it should transfer the INLINE information to the specialised function.
Otherwise, whether or not the INLNE happens can depend on whether
specialisation happens, which seems wrong.  See Note [Inline specialisation]
in Specialise.lhs

Here's the example Roman reported

    primWriteMU :: UAE e => MUArr e s -> Int -> e -> ST s ()
    {-# INLINE primWriteMU #-}
    primWriteMU = writeMBU . unMUAPrim
    ------
    
    The problem is that primWriteMU doesn't get inlined *sometimes*, which
    results in code like
    
    case Data.Array.Parallel.Unlifted.Flat.UArr.$sprimWriteMU
	    @ s11_X1nJ
	    marr_s25s
	    (GHC.Base.I# sc_s27F)
	    GHC.Base.False
	    new_s_a1Db
	    of wild3_a1Dd { (# new_s1_X1F9, r_a1Dc #) -> ...

Note the fact that we have a call to the *specialised* $sprimWriteMU.

Roman found that 
    loop :: STRef s a -> Int -> ST s Int
    loop ref n = case n of
                   0 -> return n
                   n -> loop ref (n-1)
wasn't eta-expanding nicely, despite the 'state hack'
(see Id.isStateHackType).  The reason was two-fold:

  a) a bug in CoreUtils.arityType (the Var case)

  b) the arity of a recursive function was not being
	exposed in its RHS (see commments with
	SimplEnv.addLetIdInfo

The commit fixes both.  

In order for this to work, you need to build the program first in the
normal way (without -prof), and then again with -prof and a suitable
-osuf (eg. -osuf p_o).  The compiler will pick up the object files
from the normal way for running TH expressions, when it sees -prof
together with -osuf.  If you omit the -osuf, you get an error message:

TH_genEx.hs:12:2:
    Dynamic linking required, but this is a non-standard build (eg. prof).
    You need to build the program twice: once the normal way, and then
    in the desired way using -osuf to set the object file suffix.

If you use -osuf, but haven't built the program the normal way first,
then you see:

TH_genEx.hs:12:2:
    cannot find normal object file `TH_genExLib.o'
    while linking an interpreted expression

Documentation to follow.

Fixes: #651