GitLab

MERGE TO 6.10.

Following suggestions from users, this patch improves the error message
when a GADT match needs a rigid type:

 tcfail172.hs:19:10:
     GADT pattern match in non-rigid context for `Nil'
-      Solution: add a type signature
+      Probable solution: add a type signature for `is_normal'
     In the pattern: Nil
     In the definition of `is_normal': is_normal Nil = True

Now GHC tries to tell you what to give a type signature *for*.
Thanks to Daniel Gorin and others for the suggestions.

This patch, written by Max Bolingbroke,  does two things

1.  It adds a new CoreM monad (defined in simplCore/CoreMonad),
    which is used as the top-level monad for all the Core-to-Core
    transformations (starting at SimplCore).  It supports
       * I/O (for debug printing)
       * Unique supply
       * Statistics gathering
       * Access to the HscEnv, RuleBase, Annotations, Module
    The patch therefore refactors the top "skin" of every Core-to-Core
    pass, but does not change their functionality.

2.  It adds a completely new facility to GHC: Core "annotations".
    The idea is that you can say
       {#- ANN foo (Just "Hello") #-}
    which adds the annotation (Just "Hello") to the top level function
    foo.  These annotations can be looked up in any Core-to-Core pass,
    and are persisted into interface files.  (Hence a Core-to-Core pass
    can also query the annotations of imported things.)  Furthermore,
    a Core-to-Core pass can add new annotations (eg strictness info)
    of its own, which can be queried by importing modules.

The design of the annotation system is somewhat in flux.  It's
designed to work with the (upcoming) dynamic plug-ins mechanism,
but is meanwhile independently useful.

Do not merge to 6.10!  

Up to now, the data constructor dictionary for class C as been called
":DC". But there is no reason for the colon to be at the front; indeed
it confuses the (simple-minded) pretty-printer for types.  So this
patch changes it to be "D:C".  This makes Core a lot easier to read.
Having a colon in the middle ensures that it can't clash with a user-written
data type.

Similarly I changed

  T:C 	   Data type corresponding a class dictionary (was :TC)
  D:C	   Data constructor for class dictionary (was :DC)

  NTCo:T   Coercion mapping from a newtype T to its representation type
		(was :CoT)

  TFCo:R   Coercion mapping from a data family to its respresentation type R
		(was :CoFR)

  Rn:T     The n'th respresentation data type for a data type T
		(was :RnT)


Do not merge to 6.10.

HEADS-UP: you'll need to recompile libraries from scratch.  

ROMAN: you could do the same for OccName.mkVectTyConOcc etc, if you wanted.

The issue here is what happens when we have

	(f |> co) x

where f is itself marked INLINE.  We want callSiteInline to "see" 
the fact that the function is applied, and hence have some incentive
to inline.  I've done this by extending CoreUnfold.CallCtxt with 
ValAppCtxt.  I think that should catch this case without messing up
any of the others.

Ganesh wanted to update records that involve existentials.  That 
seems reasonable to me, and this patch covers existentials, GADTs,
and data type families.

The restriction is that 
  The types of the updated fields may mention only the
  universally-quantified type variables of the data constructor

This doesn't allow everything in #2595 (it allows 'g' but not 'f' in
the ticket), but it gets a lot closer.

Lots of the new lines are comments!

The idea here is that with -XNamedFieldPuns and -XRecordWildCards we don't
want to report shadowing errors for
	let fld = <blah> in C { .. }
But to suppress such shadowing errors, the renamer needs to know that
'fld' *is* a record selector.  Hence the new NameSet in 
TcRnFypes.RecFieldEnv

In fixing #2713, this patch also eliminates two almost-unused
functions from RnEnv (lookupBndr and lookupBndr_maybe).  The
net lines of code is prety much unchanged, but more of them
are comments!

Getting the automatic deriving mechanism to work really smoothly
is surprisingly hard.  I keep finding myself in TcDeriv!

Anyway, this is a nice clean fix to Trac #2701.

The Windows builder is having problems running ps2pdf, so this works
aroudn the problem.

If the current thread blocks, we should yield the Capability
immediately, because the thread and hence possibly the current Task
are now owned by someone else.  This worked in the old scheduler, but
we moved where the yield happens in the new scheduler which broke it.

Change the way we look for work in the scheduler.  Previously,
checking to see whether there was anything to do was a
non-side-effecting operation, but this has changed now that we do
work-stealing.  This lead to a refactoring of the inner loop of the
scheduler.

Also, lots of cleanup in the new work-stealing code, but no functional
changes.

One new statistic is added to the +RTS -s output:

  SPARKS: 1430 (2 converted, 1427 pruned)

lets you know something about the use of `par` in the program.

   Spark stealing support for PARALLEL_HASKELL and THREADED_RTS versions of the RTS.
  
  Spark pools are per capability, separately allocated and held in the Capability 
  structure. The implementation uses Double-Ended Queues (deque) and cas-protected 
  access.
  
  The write end of the queue (position bottom) can only be used with
  mutual exclusion, i.e. by exactly one caller at a time.
  Multiple readers can steal()/findSpark() from the read end
  (position top), and are synchronised without a lock, based on a cas
  of the top position. One reader wins, the others return NULL for a
  failure.
  
  Work stealing is called when Capabilities find no other work (inside yieldCapability),
  and tries all capabilities 0..n-1 twice, unless a theft succeeds.
  
  Inside schedulePushWork, all considered cap.s (those which were idle and could 
  be grabbed) are woken up. Future versions should wake up capabilities immediately when 
  putting a new spark in the local pool, from newSpark().

Patch has been re-recorded due to conflicting bugfixes in the sparks.c, also fixing a 
(strange) conflict in the scheduler.

In boxy_match (which is a pure function used by preSubType) we can
encounter TyVars not just TcTyVars; this patch takes account of that.

- The current implementation of type families cannot properly deal
  with superclass equalities.  Instead of making a half-hearted attempt at
  supporting them, which mostly ends in cryptic error message, rejecting
  right away with an appropriate message.

  MERGE TO 6.10