Make exprType work correctly in the presnce of type bindings (Trac #8522)
Test Trac #8514
Wibbles
Actually increase the perf number!
Further refactoring to the tuple-typechecking patch
Detect msys2 via uname (different to msys)

uname -s
  msys gives "MINGW32"
  msys2 gives "MINGW_NT-6.2"
Test Trac #5996
Make type-level evaluation work with :kind!

The main change is to add a case to `reduceTyFamApp_maybe` to evaluate
built-in type constructors (e.g., (+), (*), and friends).

To avoid problems with recursive modules, I moved the definition of
TcBuiltInSynFamily from `FamInst` to `FamInstEnv`.  I am still not sure if
this is the right place.

There is also a wibble that it'd be nice to fix:

when we evaluate a built-in type function, using`sfMatchFam`, we get
a `TcCoercion`.  However, `reduceTyFamApp_maybe` needs a `Corecion`.
I couldn't find a nice way to convert between the two, so I resorted to
a bit of hack (marked with `XXX`).

The hack is that we happen to know that the built-in constructors for
the type-nat functions always return coercions of shape `TcAxiomRuleCo`,
with no assumptions, so it easy to convert `TcCoercion` to `Coercion`
in this one case.  This is enough to make things work, but it is clearly
a cludge.
Remove old workaround for containers <= 0.3
Remove unnecessary and deprecated inclusions of Typeable.h

The build system would've complained loudly about these inclusions if it
weren't for #8527.
Turn NameCacheUpdater into a newtype
Make the fields in NameCache strict

We've already been making sure to strictly modify the global name cache
in order to avoid space leaks.  However, that does us little good if the
fields of the name cache are not made strict as well.
Fix bug in LLVM code generator

The bitcast operation always needs a type for the source.
Update `Cabal` to 1.18.1.2 (again)

Cabal was already updated to 1.18.1.2. last month, but then got reverted
by accident by 06aac68dee100b21dc7d304fa90d9baa423507a0

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
fix a small memory leak with +RTS -hb
comments
simplify processNurseryForDead

It wasn't actually broken, but it wasn't obviously right either.
Fix some cases where we were leaving slop in the heap (#8515, #8298)
Handle ExitFailure (-sig) by killing process with signal

On Unix we now use negative exit codes in ExitFailure to indicate that a
process exited due to a signal. This patch implements the case for when
a ExitFailure exception propagates out of the top of main (and is
handled by the topHandler).

For a negative ExitFailure code, we try to kill the process using that
signal (the details of that are handled by shutdownHaskellAndSignal from
the RTS). For an exit code outside the valid ranges, we use 0xff.
Add tests for the top level exception handler

The top level exception handler is wrapped around main, and FFI exports.
It handles exceptions that are not otherwise caught in user code. For
most exception is just prints them, but handles a few specially,
including ExitCode and UserInterrupt.

On Unix it installs a signal handler for SIGINT to translate it into a
UserInterrupt async exception.

So we test that:

1. receiving SIGINT does trigger a UserInterrupt async exception
2. an unhandled UserInterrupt makes us kill ourselves with SIGINT
3. an unhandled ExitFailure (-sig) makes us kill ourselves with sig