Tools handling installed packages need to be able to interpret the
paths which are relative to the ${pkgroot} which means they need to
know the value of ${pkgroot}. With ghc-pkg this is not always obvious
since ghc-pkg does not currently have any way machine interface for
reporting the location of its package dbs (global, user). The solution
we have arrived at is simply to emit the pkgroot as an extra field
when it is needed.

There are two cases:
 * --no-expand-pkgroot: ghc-pkg dump/describe will not expand the
   ${pkgroot} var, so it will appear literally in the output and the
   pkgroot field will be generated so that tools know what value to
   use for the ${pkgroot}.
 * --expand-pkgroot: ghc-pkg dump/describe will expand the ${pkgroot}
   and ${pkgrooturl} vars and will not generate the pkgroot field.

The defaults are:
 * ghc-pkg dump/describe --no-expand-pkgroot
 * ghc-pkg field --expand-pkgroot

makes primops look cheap (but not free), and improves the Repro4.hs
example from #4978.

While I was making this change I accidentally discovered that
increasing the discount for scrutinised constructors was an
unambiguous win, so I did that too.

setupRtsFlags(), rather than sharing the memory.  Previously if the
caller of hs_init() passed in dynamically-allocated memory and then
freed it, random crashes could happen later (#5177).

The haddock-html and haddock-interface fields are now checked
as well. Had to fix up ghc-cabal as it used relative paths for
the inplace package's haddock-html. It turns out that these
were never used so it could simply be omitted.

Historically ghc implemented relocatable packages by allowing
"$topdir" in the package registration info and having ghc expand
this with its notion of $topdir. The topdir refers to where ghc
itself is installed (specifically the libdir).

The ${pkgroot} spec takes this idea and makes it portable.
(http://www.haskell.org/pipermail/libraries/2009-May/011772.html)
Instead of paths relative to where ghc is installed, they can be
relative to the package database itself. Thus it is no longer a
ghc-specific idea and can work for package collections other than
the global package db.

It was never a universal solution. It only worked with the GNU linker.
It has not been used by Cabal for ages. GHCi can now load .a files so
it will not be needed in future.

For shell-based build systems the feature is still available as:
  ghc-pkg register --expand-env-vars

Historically, ghc-pkg allowed environment variables to appear in the
input files for ghc-pkg register. They are not stored in the package
database but are expanded upon registration. This feature helped for
build systems based on makefiles and shell scripts. These days the
vast majority of such files are generated by Cabal and we don't want
any ${name} strings (e.g. perhaps in a package description) getting
accidentally interpreted as an environment variable.

in the future.

The Haskell' committee decided to remove datatype contexts from the language:
http://www.haskell.org/pipermail/haskell-prime/2011-January/003335.html

some more tests to run (those with reqlib('mtl')) and serves as an
extra sanity check on Cabal and the bindist.

program is improved quite dramatically (fft2 30% less allocation), and
everything else was unchanged.

heuristics work better.  Also removed the old unused "needs_wrapper"
predicate for primops.  This helps with #4978.

This improves the code generated for the examples in #4978, and
appears to make very little difference to nofib.

* 'master' of /home/simonmar/ghc-git/.:
  Revert "Add capability sets to the event system. Contains code from Duncan Coutts."

This reverts commit 58532eb4.
Turns out it didn't work on Windows and it'll need some non-trivial changes
to make it work on Windows. We'll get it in later once that's sorted out.

This commit adds fingerprint.py python script that can be used to
create and restore "fingerprints" of a ghc repo configuration. A
fingerprint is a list of (sub-repo, commit) pairs. It can be used in
place of git submodules to record and reinstate the entire commit
state of the git repos used by ghc.

Fixed conflicts in:
	compiler/typecheck/TcCanonical.lhs
	compiler/typecheck/TcErrors.lhs
	compiler/typecheck/TcInteract.lhs

canonicalization. We now check whether the returned
coercion is an identity coercion. We used to check
whether we return any constraints from flattening but
that's wrong in the presence of the flattening cache.

Original patch by Orphi <MathematicalOrchid@hotmail.com>
Plus a few miscellaneous updates from me.