GitLab

This large checkin is the new ghc version of Haskell
Program Coverage, an expression-level coverage tool for Haskell.

Parts:

 - Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files.
 - Coverage.lhs - Annotates the HsSyn with coverage tickboxes.
  - New Note's in Core,
      - TickBox      -- ticked on entry to sub-expression
      - BinaryTickBox  -- ticked on exit to sub-expression, depending
	       	     -- on the boolean result.

  - New Stg level TickBox (no BinaryTickBoxes, though) 

You can run the coverage tool with -fhpc at compile time. 
Main must be compiled with -fhpc. 
				      

In preparation for parallel GC, split up the monolithic GC.c file into
smaller parts.  Also in this patch (and difficult to separate,
unfortunatley):
  
  - Don't include Stable.h in Rts.h, instead just include it where
    necessary.
  
  - consistently use STATIC_INLINE in source files, and INLINE_HEADER
    in header files.  STATIC_INLINE is now turned off when DEBUG is on,
    to make debugging easier.
  
  - The GC no longer takes the get_roots function as an argument.
    We weren't making use of this generalisation.

I don't think this can ever be useful, because to add more roots you
need to do it consistently for every GC.  The right way to add roots
is to use newStablePtr.

should fix profiling and unreg in HEAD

- Not sure whether I do the right thing, because I don't understand the
  doc stuff.  However, the original code was definitely wrong and
  breaking the renaming of family instance declarations.
- The important point is that in

    data instance T pats = rhs

  T is *not* a defining occurence of T (similarly as C is not a defining
  occurence in "instance C Int").

- `RnNames.nubAvails', which amalgamates AvailInfo items that belong to the 
  same parent, needs to be careful that the parent name occurs first if it is
  in the list of subnames at all.  (Otherwise, we can get funny export items
  in ifaces.)
- I discovered this while debugging family import/exports, but I am pretty 
  sure the bug would also have shown up without using families under the 
  right circumstances.

Given

  module Exp (T)
  where

  class C a where
    data T a :: *

we need the AvailInfo for the export item to be C|{T}, not just T.
This patch achieves that under the new name parent scheme.

Associated types in import lists require special care and the new name
parent code broke that.  What's the problem?  in the presence of ATs
the name parent relation can have a depth of two (not just one as in H98).
Here is an example:

  class GMapKey a where
    data GMap a :: * -> *
  instance GMapKey Int where
    data GMap Int v = GMapInt ...

The data constructor GMapInt's parent is GMap whose parent in turn is the 
class GMapKey; ie, GMapKey is GMapInt's grand parent.  In H98, data types 
have no parents (which is in some places in the code represented by making 
them their own parent).

I fixed this by extending the information in filterImport's occ_env and
taking the case of associated types explicitly in consideration when 
processing the various forms of IE items.

- Its important that `isImplicitTyCon' considers
  (a) associated families to be implicit, but
  (b) considers family instances *not* to be implicit (for the same reasons 
      that a dfun is not implicit).

GHC's code generator can only enter a closure if it's guaranteed
not to be a function.  In the Dynamic module, we were using the 
type (forall a.a) as the type to which the dynamic type was unsafely
cast:
	type Obj = forall a.a

Gut alas this polytype was sometimes instantiated to (), something 
like this (it only bit when profiling was enabled)
	let y::() = dyn ()
	in (y `cast` ..) p q
As a result, an ASSERT in ClosureInfo fired (hooray).

I've tided this up by making a new, primitive, lifted type Any, and
arranging that Dynamic uses Any, thus:
	type Obj = ANy

While I was at it, I also arranged that when the type checker instantiates 
un-constrained type variables, it now instantiates them to Any, not ()
	e.g.  length Any []

[There remains a Horrible Hack when we want Any-like things at arbitrary 
kinds.  This essentially never happens, but see comments with 
TysPrim.mkAnyPrimTyCon.]

Anyway, this fixes Trac #905

I'm not sure what the significance of the "arity" of a primtive
TyCon is.  They aren't necessarily saturated, so it's not that.

I rather think that arity is only relevant for 
	SynTyCon 
	AlgTyCon
	CoercionTyCon

This comment (and commit message) is just an aide memoire.

A GHC binary can generally build either registerised or unregisterised
code, unless it is unregisterised only.  

The previous changes broke this, but I think I've now restored it.