GitLab

I boobed when I decoupled record selectors from their data types.
The most straightforward and robust fix means attaching the TyCon
of a record selector to its IfaceIdInfo, so 

   you'll need to rebuild all .hi files

That said, the fix is easy.

In particular, in the integer-gmp package the C and CMM code depends
on the size of STG structures, which vary between ways.

Behind the scenes, the new IO library always does buffering for read
Handles regardless of NoBuffering.  Normally this isn't visible, but
it causes a problem in GHCi where there are two stdin Handles.

This should fix those ghci test failures that sprung up in full
testsuite runs recently.

Previously this rule had a sanity check for the existence of the .o
file.  However, the sanity check is expensive, especially on Windows,
because it requires spawning a shell.  So now we use an empty command
here.

This change reduced the time to do 'make' in an up-to-date tree on
Windows from 33s to 16s for me.  (the actual saving depends on how
much rebuilding you've been doing, and how many .hi files are older
than their .o files).

The comments in this file now describe various versions of the rule
that don't work.

integer-gmp's Integer is now wrapped by an Integer type in integer.

Fixes ghci loading gmp on Windows

When configure tests for a feature it may not generate warning-free C
code, and thus may think that the feature doesn't exist if -Werror is
on.

Nothing from gmp is used in the rts anymore.

and remove the implementations of stg(Alloc|Realloc|Dealloc)ForGMP

The implementations are still in the rts.

In particular we need alloc_blocks and alloc_blocks_lim for MAYBE_GC.
The gmp cmm primops also use stg_ARR_WORDS_info.

We need this, or something equivalent, to be able to implement
stgAllocForGMP outside of the rts. That's because we want to use
allocateLocal which allocates from the given capability without
having to take any locks. In the gmp primops we're basically in
an unsafe foreign call, that is a context where we hold a current
capability. So it's safe for us to use allocateLocal. We just
need a way to get the current capability. The method to get the
current capability varies depends on whether we're using the
threaded rts or not. When stgAllocForGMP is built inside the rts
that's ok because we can do it conditionally on THREADED_RTS.
Outside the rts we need a single api we can call without knowing
if we're talking to a threaded rts or not, hence this addition.

In practise currently you also need UnliftedFFITypes, however
the restriction to just unlifted types may be lifted in future.

We don't handle "foreign import prim" in TH stuff. 

The safe/unsafe annotation doesn't currently mean anything for prim.
Just in case we decide it means something later it's better to stick
to using one or the other consistently. We decided that using safe
is the better one to require (and it's also the default).

It adds a third case to StgOp which already hold StgPrimOp and StgFCallOp.
The code generation for the new StgPrimCallOp case is almost exactly the
same as for out-of-line primops. They now share the tailCallPrim function.
In the Core -> STG translation we map foreign calls using the "prim"
calling convention to the StgPrimCallOp case. This is because in Core we
represent prim calls using the ForeignCall stuff. At the STG level however
the prim calls are really much more like primops than foreign calls.

Unlike normal foreign imports which desugar into a separate worker and
wrapper, we use just a single wrapper decleration. The representation
in Core of the call is currently as a foreign call. This means the
args are all treated as fully strict. This is ok at the moment because
we restrict the types for foreign import prim to be of unboxed types,
however in future we may want to make prim imports be the normal cmm
calling convention for Haskell functions, in which case we would not
be able to assume all args are strict. At that point it may make more
sense to represent cmm/prim calls distinct from foreign calls, and
more like the we the existing PrimOp calls are handled.

The main restriction is that all args and results must be unboxed types.
In particular we allow unboxed tuple results (which is a primary
motivation for the whole feature). The normal rules apply about
"void rep" result types like State#. We only allow "prim" calling
convention for import, not export. The other forms of import, "dynamic",
"wrapper" and data label are banned as a conseqence of checking that the
imported name is a valid C string. We currently require prim imports to
be marked unsafe, though this is essentially arbitrary as the safety
information is unused.

We only allow simple function label imports, not the normal complicated
business with "wrapper" "dynamic" or data label "&var" imports.