GitLab

This is patch that adds support for interruptible FFI calls in the form
of a new foreign import keyword 'interruptible', which can be used
instead of 'safe' or 'unsafe'.  Interruptible FFI calls act like safe
FFI calls, except that the worker thread they run on may be interrupted.

Internally, it replaces BlockedOnCCall_NoUnblockEx with
BlockedOnCCall_Interruptible, and changes the behavior of the RTS
to not modify the TSO_ flags on the event of an FFI call from
a thread that was interruptible.  It also modifies the bytecode
format for foreign call, adding an extra Word16 to indicate
interruptibility.

The semantics of interruption vary from platform to platform, but the
intent is that any blocking system calls are aborted with an error code.
This is most useful for making function calls to system library
functions that support interrupting.  There is no support for pre-Vista
Windows.

There is a partner testsuite patch which adds several tests for this
functionality.

We still have
    insertList, insertListWith, deleteList
which aren't in Data.Map, and
    foldRightWithKey
which works around the fold(r)WithKey addition and deprecation.

This major patch implements the new OutsideIn constraint solving
algorithm in the typecheker, following our JFP paper "Modular type
inference with local assumptions".  

Done with major help from Dimitrios Vytiniotis and Brent Yorgey.

We were keeping things as Int, and then converting them to Word16 at
the last minute, when really they ought to have been Word16 all along.

It turns out we can easily support breakpoints on expressions with
unlifted types, by translating 

  case tick# of _ -> e

into

  let f = \s . case tick# of _ -> e 
  in  f realWorld#

instead of just a plain let-binding.  This is the same trick that GHC
uses for abstracting join points of unlifted type.

In #2845, GHC has eta-expanded the tick expression, changing the
result type from IO a to (# State#, a #), which was the reason the
tick was suddenly being ignored.  By supporting ticks on unlifted
expressions we can make it work again, although some confusion might
arise because _result will no longer be available (it now has
unboxed-tuple type, so we can't bind it in the environment).  The
underlying problem here is that GHC does transformations like
eta-expanding the tick expressions, and there's nothing we can do to
prevent that.

We used to generated things like:
    extern StgWordArray (newCAF) __attribute__((aligned (8)));
    ((void (*)(void *))(W_)&newCAF)((void *)R1.w);
(which is to say, pretend that newCAF is some data, then cast it to a
function and call it).
This goes wrong on at least IA64, where:
    A function pointer on the ia64 does not point to the first byte of
    code. Intsead, it points to a structure that describes the function.
    The first quadword in the structure is the address of the first byte
    of code
so we end up dereferencing function pointers one time too many, and
segfaulting.

There was a leftover big lambda in the CorePrep'd code, which confused
the bytecode generator.  Actually big lambdas are harmless.  This patch
refactors ByteCodeGen so that it systemantically used 'bcView' to eliminate
junk.  I did a little clean up in CorePrep too.

See comments in Trac #2898.

This replaces the hand-rolled architecture-specific FFI support in
GHCi with the standard libffi as used in GCJ, Python and other
projects.  I've bundled the complete libffi-3.0.4 tarball in the
source tree in the same way as we do for GMP, the difference being
that we always build and install our own libffi regardless of whether
there's one on the system (it's small, and we don't want
dependency/versioning headaches).

In particular this means that unregisterised builds will now have a
fully working GHCi including FFI out of the box, provided libffi
supports the platform.

There is also code in the RTS to use libffi in place of
rts/Adjustor.c, but it is currently not enabled if we already have
support in Adjustor.c for the current platform.  We need to assess the
performance impact before using libffi here too (in GHCi we don't care
too much about performance).

This means that an unregisterised build on a platform not directly
supported by GHC can now have full FFI support using libffi.

Also in this commit:

 - use PrimRep rather than CgRep to describe FFI args in the byte
   code generator.  No functional changes, but PrimRep is more correct.

 - change TyCon.sizeofPrimRep to primRepSizeW, which is more useful

The extra safe points introduced for breakpoints were previously
compiled as normal updatable thunks, but they are guaranteed
single-entry, so we can use non-updatable thunks here.  This restores
the tail-call property where it was lost in some cases (although stack
squeezing probably often recovered it), and should improve
performance.

An AP_STACK now ensures that there is at least AP_STACK_SPLIM words of
stack headroom available after unpacking the payload.  Continuations
that require more than AP_STACK_SPLIM words of stack must do their own
stack checks instead of aggregating their stack usage into the parent
frame.  I have made this change for the interpreter, but not for
compiled code yet - we should do this in the glorious rewrite of the
code generator.

Older GHCs can't parse OPTIONS_GHC.
This also changes the URL referenced for the -w options from
WorkingConventions#Warnings to CodingStyle#Warnings for the compiler
modules.

We don't support arbitrary unboxed tuples in GHCi right now.

Now I can single step through Happy-generated parsers

  - move parts of the debugger implementation below the GHC API where
    they belong.  There is still more in Debugger that violates the
    layering, hopefully I'll get to that later.

  - instead of returning an IO action from runStmt for resuming,
    return a ResumeHandle that is passed to GHC.resume.

  - breakpoints now return [Name] which is displayed in the same
    way as when a binding statement is executed.

  - :load, :add, :reload now clear the active breakpoints and context

  - :break gives a sensible error when used on a non-interpreted module

  - export breakpoint-related types from GHC

  - remove a bunch of layer-violating imports from InteractiveUI

  - remove some more vestiges of the old breakpoint code (topLevel in
    the GHCi state).

  - remove TickTree and use a simple array instead, cached per module

This is the result of Bernie Pope's internship work at MSR Cambridge,
with some subsequent improvements by me.  The main plan was to

 (a) Reduce the overhead for breakpoints, so we could enable 
     the feature by default without incurrent a significant penalty
 (b) Scatter more breakpoint sites throughout the code

Currently we can set a breakpoint on almost any subexpression, and the
overhead is around 1.5x slower than normal GHCi.  I hope to be able to
get this down further and/or allow breakpoints to be turned off.

This patch also fixes up :print following the recent changes to
constructor info tables.  (most of the :print tests now pass)

We now support single-stepping, which just enables all breakpoints.

  :step <expr>     executes <expr> with single-stepping turned on
  :step            single-steps from the current breakpoint

The mechanism is quite different to the previous implementation.  We
share code with the HPC (haskell program coverage) implementation now.
The coverage pass annotates source code with "tick" locations which
are tracked by the coverage tool.  In GHCi, each "tick" becomes a
potential breakpoint location.

Previously breakpoints were compiled into code that magically invoked
a nested instance of GHCi.  Now, a breakpoint causes the current
thread to block and control is returned to GHCi.

See the wiki page for more details and the current ToDo list:

  http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger