GitLab

copyPart() was still using the old WHITEHOLE mechanism for locking the
closure.  I don't think this fixes any actual bugs, but it removes a
gratuitous difference between two functions that should look similar.

Fixes crash in concprog002(threaded2_qw), and possibly other problems

Otherwise, finalizer callbacks cause a deadlock in the threaded RTS
(including GHCi)

Now that the haskell98 dependency of GHC has been removed, the
Happy-generated parsers must import Data.Array rather than Array, and
that change was made in Happy 1.16.

Somehow this got lost, probably in the recent RTS tidy-up.  
Fixes segfaults in unregisterised compilation.

Fixes this failure in the unreigsterised build:
  /usr/bin/ld: cannot find -lHSrts_thr

Turns out using atomic update instead of a full-blown lock was easier
than I thought.  It should also be safe in the case where we
concurrently read the same interface file.  Whichever thread loses the
race will simply find that all of the names are already defined and
will have no effect on the name cache.

There were two bugs, and had it not been for the first one we would
not have noticed the second one, so this is quite fortunate.

The first bug is in stg_unblockAsyncExceptionszh_ret, when we found a
pending exception to raise, but don't end up raising it, there was a
missing adjustment to the stack pointer.  

The second bug was that this case was actually happening at all: it
ought to be incredibly rare, because the pending exception thread
would have to be killed between us finding it and attempting to raise
the exception.  This made me suspicious.  It turned out that there was
a race condition on the tso->flags field; multiple threads were
updating this bitmask field non-atomically (one of the bits is the
dirty-bit for the generational GC).  The fix is to move the dirty bit
into its own field of the TSO, making the TSO one word larger (sadly).

  
The current implementation is rather pessimistic.  The persistent
linker state is now an MVar and all exported Linker functions are
wrapped in modifyMVar calls.  This is serves as a big lock around all
linker functions.

There might be a chance for more concurrency in a few places. E.g.,
extending the closure environment and loading packages might be
independent in some cases.  But for now it's better to be on the safe
side.

'readBinIface' updates the name cache in a way that is hard to use
with atomicModifyIORef, so this patch introduces a lock for this case.
All other updates use atomicModifyIORef.

Having a single lock is quite pessimistic, so it remains to be seen
whether this will become a problem.  In principle we only need to make
sure that we do not load the same file concurrently (or that it's
idempotent).  In practice we also need to ensure that concurrent reads
do not cancel each other out (since the new NameCache may be based on
an outdated version).

Flushing and uncaching a single module is not completely atomic since
both caches a cleared separately.  However, flushing is only done when
changing the working directory which shouldn't be done concurrently to
other threads.  Uncaching is only done in 'summariseModule' which
requires some more work to become thread-safe anyway.

This patch tides up Ian's fix a little. In particular, if if you
{-# SOURCE #-} import a module from a different package, you now 
get a much more civlised error message.

Suppose we import anotherPackage:M, which exports things from
anotherPackage:Internal. Then GHC will want to read
anotherPackage:Internal.hi.

However, if we have also SOURCE-imported thisPackage:Internal then
we don't want GHC to try to read anotherPackage:Internal.hi-boot
instead.

The mapping that tells us whether a module is SOURCE-imported uses just
the module name for the key, so we have to check the package ID before
looking it up.

Fixes #3007.

Type synonyms that don't mention one of their type parameters on the 
RHS are a pain in the neck.  This patch fixes a long-standing bug (that
simply has not appeared before) in that exprType could return a type
mentioning an existentially-quantified variable (in one of those ignored
argument positions).

See CoreUtils Note [Existential variables and silly type synonyms]

The fix is not entirely beautiful, but it works, and is very localised.