GitLab

bug in zonking: we must zonk the kinds of existential variables even if
the variables themselves will not be affected.

This is quite tricky, with examples like this:

import Control.Arrow

pRepeat :: a -> [a]
pRepeat =
    proc x -> do
      rec
        s <- returnA -< f_rec x:s       -- f_rec is monomorphic here
        let f_later y = y               -- f_later is polymorphic here
        _ <- returnA -< (f_later True, f_later 'a')
        let f_rec y = y                 -- f_rec is polymorphic here
      returnA -< f_later s              -- f_later is monomorphic here

Fixed the typechecking of arrow RecStmt to track changes to the monad
version.  It was simplest to add a field recS_later_rets corresponding
to recS_rec_rets.  It's only used for the arrow version, and always
empty for the monad version.  But I think it would be cleaner to put
the rec_ids and later_ids in a single list with supplementary info
saying how they're used.

Also fixed several glitches in the desugaring of arrow RecStmt.  The fact
that the monomorphic variables shadow their polymorphic counterparts is a
major pain.  Also a bit of general cleanup of DsArrows while I was there.

We already have a class OutputableBndr; this patch adds
methods pprInfixOcc and pprPrefixOcc, so that we can get
rid of the hideous hack (the old) Outputable.pprHsVar.

The hack was exposed by Trac #5657, which is thereby fixed.

We no longer have many separate, clashing getDynFlags functions

I've given each GhcMonad its own HasDynFlags instance, rather than
using UndecidableInstances to make a GhcMonad m => HasDynFlags m
instance.

We now require GHC >= 7.0, which has the behaviour we want.

dmp authored Dec 07, 2011 and Simon Marlow committed Dec 19, 2011

This commit swaps the import order of Rts.h and Stg.h in
StgCRun.c for non-SPARC architectures. Swapping the import
order prevents the declaration of the global registers thus
allowing the GHC runtime to be compiled by LLVM-based C
compilers.

LLVM-base C compilers cannot use the global register
declarations (for R1, R2, etc.) because they use
GCC-specific extensions. The declarations are not needed in
StgCRun.c except for the SPARC architecture. The other
architectures use hand-written assembly that accesses the
appropriate register directly.

Makes #5612 fail in a more civilized way, at least.

This patch allows setNumCapabilities to /reduce/ the number of active
capabilities as well as increase it.  This is particularly tricky to
do, because a Capability is a large data structure and ties into the
rest of the system in many ways.  Trying to clean it all up would be
extremely error prone.

So instead, the solution is to mark the extra capabilities as
"disabled".  This has the following consequences:

  - threads on a disabled capability are migrated away by the
    scheduler loop

  - disabled capabilities do not participate in GC
    (see scheduleDoGC())

  - No spark threads are created on this capability
    (see scheduleActivateSpark())

  - We do not attempt to migrate threads *to* a disabled
    capability (see schedulePushWork()).

So a disabled capability should do no work, and does not participate
in GC, although it remains alive in other respects.  For example, a
blocked thread might wake up on a disabled capability, and it will get
quickly migrated to a live capability.  A disabled capability can
still initiate GC if necessary.  Indeed, it turns out to be hard to
migrate bound threads, so we wait until the next GC to do this (see
comments for details).

Although scalar functions can use any scalar data type, their arguments and functions may only involve primitive types at the moment.