GitLab

so that exceptions are reported with "*** Exception" instead of as a panic.

The problem is that we install the client's CWD before calling
runStmt, but runStmt has to load modules before running the code.  We
need to install the CWD just before running the code instead, which
means it has to be done inside runStmt (and resume).

It now uses the standard warning log and error reporting mechanism.

This used to be necessary when our I/O library needed all FDs in
O_NONBLOCK mode, and readline used to put stdin back into blocking
mode.  Nowadays the I/O library can cope with FDs in blocking mode,
and #2778/#2777 show why this is important.

Ifdefs for whether we had extensible exceptions or not were spreading
through GHC's source, and things would only have got worse for the next
2-3 years, so instead we now use an implementation of extensible
exceptions built on top of the old exception type.

nameModule fails on an InternalName.  These ASSERTS tell you
which call failed.

To get the ModSummary for a ModuleName getModSummary can be used.
It's not called find* or lookup* because it assumes that the module is
in the module graph and throws an exception if it cannot be found.
Overall, I'm not quite sure about the usefulness of this function
since the user has no control about which filetype to grab (hs or
hs-boot).

New form of :load in GHCi:

> :load *A

forces A to be loaded as byte-code.  See the manual for details.  The
previous behaviour for specifying filenames vs. module names on the
command line and in :load has been restored.

The Target datatype has a new Bool field, which is True if the target
is allowed to be loaded from compiled code, or False otherwise, so
this functionality is available via the GHC API.  guessTarget
understands the *-prefix form for specifying targets.

I'm not 100% sure if this is the right fix, but it seems sensible and
stops break008 segfaulting for me on amd64/Linux.

TopHandler now uses the new extensible exceptions module, so we
need to interact with it using the new types.

These are needed for GLOBAL_VAR's to work properly

* Allow -ffoo flags to be deprecated
* Mark some -ffoo flags as deprecated
* Avoid using deprecated flags in error messages, in the build system, etc
* Add a flag to en/disable the deprecated flag warning

This is a much more robust way to do recompilation checking.  The idea
is to create a fingerprint of the ABI of an interface, and track
dependencies by recording the fingerprints of ABIs that a module
depends on.  If any of those ABIs have changed, then we need to
recompile.

In bug #1372 we weren't recording dependencies on package modules,
this patch fixes that by recording fingerprints of package modules
that we depend on.  Within a package there is still fine-grained
recompilation avoidance as before.

We currently use MD5 for fingerprints, being a good compromise between
efficiency and security.  We're not worried about attackers, but we
are worried about accidental collisions.

All the MD5 sums do make interface files a bit bigger, but compile
times on the whole are about the same as before.  Recompilation
avoidance should be a bit more accurate than in 6.8.2 due to fixing
#1959, especially when using -O.

This fixes the issue where :list would stop working if the
program being debugged side-effected the working directory,
and should prevent other similar issues