GitLab

- Fix two distinct bugs, one in MkId.mkDataConIds, one in DataCon.mkDataCon
- Add more comments
- Add a little assertion checking in TyCon

Type-family tests now work.

Tom S found this bug by inspection; we've never seen it
fail in the wild, but it was obviosly Utterly Wrong

This was being done already for each binding added by :print,
but :sprint does not add any new binding, so we take care of it 
separately 

 - .tix files are now a list of MixModule, which contain a hash of the contents of the .mix file.
 - .mix files now have (the same) hash number.

This changes allow different binaries that use the same module compiled in the same way
to share coverage information.

It wasn't a good idea to disable it

Now we require that configure fails, and use our own signalling rather
than Cabal's buildable field.

This fixes a problem where patches altering the darcs-all script break
on Windows as the file is open. The script is now also slightly nicer,
on balance.

Sometimes parts of a source file come from different places due to
preprocessing, and the lines can overlap.

Now I can single step through Happy-generated parsers

See bug #1295

Now that constructor info tables contain the name of the constructor,
we can generate useful heap profiles without requiring the whole
program and libraries to be compiled with -prof.  So now, "+RTS -hT"
generates a heap profile for any program, dividing the profile by
constructor.  It wouldn't be hard to add support for grouping
constructors by module, or to restrict the profile to certain
constructors/modules/packages.

This means that for the first time we can get heap profiles for GHCi,
which was previously impossible because the byte-code
interpreter and linker don't work with -prof.

It looks like this was accidentally replaced with '?' in the patch
"HsSyn clean up for indexed types".  (see bug #1294)

If you compiled a program with -ticky and ran it with:
./foo +RTS -rstderr -RTS
the result would be a segfault. This was because the RTS interprets stderr to
mean "use debugBelch to print out messages," and sets the ticky file pointer
to NULL as a result, but PrintTickyInfo (the function in Ticky.c that prints
out the ticky report) wasn't checking for NULL.

I changed PrintTickyInfo to check whether the ticky file pointer is NULL and 
output to stderr if so.

Also removed an unused import from CodeOutput.lhs.

I introduced a bug yesterday when I changed the way tidying up was performed.
As a result of tidying,  cvObtainTerm could be returning types 
with regular tyvars inside, which never should.

But actually, it's better if we do not do the tidying up, in order to 
keep the tyvar names from the environment.
New names will be introduced only when an existential is found, which
is not so common. In this case the user will see a funny name. 
Is that really an issue?