.|ab5aad58
ghc-tarballs|e7b7b152083f7c3e3559e557a239757d41ac02a6
libraries/Cabal|6f01f56a2702b50e2da909566c4a01622cb2ca7f
libraries/Win32|0cf603103e9ad3fccd862171ba5e689b87930622
libraries/array|e4b4e2e0a79f4138bdff4f10d263436b0155f449
libraries/base|be2750a0a11b919fb03cc070074e430f88bdfa90
libraries/binary|749ac0efbde3b14901417364a872796598747aaf
libraries/bytestring|cab9d8566fba8611598f14fb4f2ac7b8d4aae75b
libraries/containers|592f6d9da9090e8d53432f22a01bb117fea2246c
libraries/deepseq|91e8a93b15ed32af3941f81e927291a023feb369
libraries/directory|3a0f2e2cb94c3e4f346023acc7201409d2876ed8
libraries/extensible-exceptions|a667b48d0cb6469b6611cb516d16836aa002e782
libraries/filepath|92d211a2752fe8827582ae0d97efd18722ad3d87
libraries/ghc-prim|7fcfc880853fa399c9468049aeb14e6eadb9eae5
libraries/haskeline|125ee5bba59fa9ac2fd77aa3922c30dffc11b7b5
libraries/haskell2010|f90687bee55adfd693fe460f2ab4bc270a7f97e3
libraries/haskell98|eb655b0317665acb9670025480b4af4465bc8f55
libraries/hoopl|0febb7f04ff4326bd120fc75549845e5e9678d72
libraries/hpc|fce8babbc3f60fb195d84545753dc342422ab8e1
libraries/integer-gmp|2567c97aaa467cb676a6ecc2cf840c92ee1cb6ec
libraries/integer-simple|c3e9c0268b4d59895829e429d1ac767e6041b06a
libraries/mtl|a748dfa2770af1d348dfaa8ad6955b25b4935711
libraries/old-locale|7f09f55ea3011c17c526805f099394a05ec9c3fe
libraries/old-time|6aae8dc2f13cef6ab48c5436c6c0e7c1b5ae3f51
libraries/parallel|f82611fac439236e22a057cd555bb9fe393597b0
libraries/pretty|e00aa7e0f82fc6f13ad85f1b3a27f53efe473e60
libraries/process|d1c2999473ba0d4ceafdc6da309debca83f91abe
libraries/random|ba8cb1b9fdfddeb29fdfedd8612c8ce85a987af8
libraries/stm|ccc6d74872916e5de7747df4cc61f64de64be591
libraries/template-haskell|acd4c3292d0f7a222a1f4f426054e4732a809fc8
libraries/terminfo|f4476f1881085b74dbe65cf4a4561e8fb34017d4
libraries/unix|c9a0bf119ce343b291bef77828066339e94fb64d
libraries/utf8-string|d28cd1fbd4ebaaa0608c070bd02ed72dc9b70399
libraries/xhtml|9a4d7d64d0491a1844d5b5759275b029ccd1e2cd
nofib|6d3ea16e56bd99d060e778fab3583aa67a6b50d4
testsuite|6560613138d61afddd0d8d428254370f8dfdb4cd
utils/haddock|1d8143659a81cf9611668348e33fd0775c7ab1d2
utils/hsc2hs|c46eed44ce96f1719334ffb190eddf63695bc553

globalisation.

branch.

This implements the independent local-heap GC described in the paper
"Multicore Garbage Collection with Local Heaps".

was [(Module, Maybe ImportDecl)], now it is just [ImportDecl].  So now
":m +A" and "import A" do exactly the same thing in GHCi, and use the
same code paths.

makes it easier to remove everything built with stage1 in cases where
the build system or GHC wrongly thinks everything is up to date.

The process ID, parent process ID, rts name and version
The program arguments and environment.

We trace the creation and shutdown of capabilities. All the capabilities
in the process are assigned to one capabilitiy set of OS-process type.

This is a second version of the patch. Includes work by Spencer Janssen.

Rather than doing it differently for the eventlog and Dtrace cases.

This is mostly for the beneift of having sensible places to put tracing
code later. We want a code path that has somewhere to trace (in order):
 (1) starting up all capabilities;
 (2) N * starting up an individual capability;
 (3) N * shutting down an individual capability;
 (4) shutting down all capabilities.
This has to work in both threaded and non-threaded modes.

Locations (1) and (2) are provided by initCapabilities and
initCapability respectively. Previously, there was no loccation for (4)
and while shutdownCapability should be usable for (3) it was only called
in the !THREADED_RTS case.

Now, shutdownCapability is called unconditionally (and the body is
conditonal on THREADED_RTS) and there is a new shutdownCapabilities that
calls shutdownCapability in a loop.

This is the offending message:
  SpecConstr
      Function `$wks2{v s2dJ} [lid]'
        has one call pattern, but the limit is 0
      Use -fspec-constr-count=n to set the bound
      Use -dppr-debug to see specialisations

The message isn't very good, and is for experts only. So now it
comes out only
    if you build with -DDEBUG
    or you specify -dppr-debug at runtime

when kind-checking in Core Lint.  It's unusual
becuase it is poly-kinded; for example

	(~) Int a
and	(~) Maybe b

are both ok.  We don't want the full generality
of kind polymorphism (yet anyway) so these changes
in effect give (~) its own private kinding rule.

It won't work right if (~) appears un-saturated,
and Lint now checks for that too.

when doing the overlap check.  We only need to load the
ones for modules whose family instances we need to compare!

This means that programs that don't use type families are
not penalised, which is important.

- Check GenericSig in tcClassSigs, along with TypeSig
- Add the generic default methods to the type envt
- Look them up via tcLookupId in TcClassDcl.tcDefMeth

Much nicer!

CoreUnfold.sizeExpr (oops, forgot to push this patch along with the
others yesterday, and this caused a few test failures overnight).

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.