GitLab

This allows us to import values (i.e. non-functions) with the CAPI.
This means we can access values even if (on some or all platforms)
they are simple #defines.

We no longer parse "staticfoo" as "static foo".

stdout/stderr might be closed, so we can't just hFlush them.
So we instead allow configuration in the same way that log_action
is configurable.

Currently no NCGs support it

No special-casing in any NCGs yet

Currently it does nothing, as x86_64 supports all the callishMachOps
that expandCallishMachOp expands, but it might be needed in the future.

Jose's patch implementing kind-polymorphic core (09015be8) reverted many of the simplifying changes to interface file TyCon serialization I had made in a previous patch (5d7173f9). Based on the diff I think this was an unintended consequence of how Jose did the merge rather than a real change he intended to make.

In fact, as a result of kind-polymorphic core we don't need to treat the Any TyCon specially any longer so my old simplifying changes can be made even simpler: IfaceTyCon is now just a newtype on IfaceExtName.

It's not clear whether it's desirable or not, and it turns out that
the way we use coercions in GHC means we tend to lose information
about type synonyms.

I've also renamed the bindisttest install directory to contain multiple
spaces, so we are also testing that multiple spaces aren't getting
collapsed into a single space.

This reverts the relaxation in c6b0fd62

Only amd64 has an efficient implementation currently.

Moved the default case of genCCall64 out into a separate function

You can now say
    data {-# CTYPE "some_header.h" "the C type" #-} Foo = ...

I think it's rare that this will actually be needed. If the
header for a CAPI FFI import includes a
    void f(ctype x);
prototype then ctype must already be defined.

However, if the header only has
    #define f(p) p->j
then the type need not be defined.

But either way, it seems good practice for us to specify the header that
we need.

to emit kind constraints when decomposing an application.
Resulting code is actually shorter!

Also add notes about unsafeCoerce

The general thread here is to reduce use of ArgKind after
the type checker; it is so fragile!