Add JS backend adapted from the GHCJS project by Luite Stegeman.

Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.

Bump array submodule

Work funded by IOG.

Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

As described in #17449, PartialDownsweep is currently fragile due to its
dependence on the error messages produced by the C preprocessor. To eliminate
this dependence we simply ignore stderr output, instead relying on the fact
that the test will exit with a non-zero exit code on failure.

Fixes #17449.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

Strangely the path it emits contains duplicate path delimiters (#16772),
```patch
--- ghc-api/downsweep/OldModLocation.run/OldModLocation.stderr.normalised	2019-06-04 14:40:26.326075000 +0000
+++ ghc-api/downsweep/OldModLocation.run/OldModLocation.run.stderr.normalised	2019-06-04 14:40:26.328029200 +0000
@@ -1 +1 @@
-[Just "A.hs",Just "mydir/B.hs"]
+[Just "A.hs",Just "mydir//B.hs"]
```

Daniel Gröber (dxld) authored 5 years ago and Marge Bot committed 5 years ago

This changes the way preprocessor failures are presented to the
user. Previously the user would simply get an unlocated message on stderr
such as:

    `gcc' failed in phase `C pre-processor'. (Exit code: 1)

Now at the problematic source file is mentioned:

    A.hs:1:1: error:
        `gcc' failed in phase `C pre-processor'. (Exit code: 1)

This also makes live easier for GHC API clients as the preprocessor error
is now thrown as a SourceError exception.

Daniel Gröber (dxld) authored 5 years ago and Marge Bot committed 5 years ago

This enables API clients to handle such errors instead of immideately
crashing in the face of some kinds of user errors, which is arguably quite
bad UX.

Fixes #10887

Daniel Gröber (dxld) authored 5 years ago and Marge Bot committed 5 years ago

This introduces a slight change of behaviour in the interrest of keeping
the code simple: Previously summariseModule would not call
addHomeModuleToFinder for summaries that are being re-used but now we do.

We're forced to to do this in summariseFile because the file being
summarised might not even be on the regular search path! So if GHC is to
find it at all we have to pre-populate the cache with its location. For
modules however the finder cache is really just a cache so we don't have to
pre-populate it with the module's location.

As straightforward as that seems I did almost manage to introduce a bug (or
so I thought) because the call to addHomeModuleToFinder I copied from
summariseFile used to use `ms_location old_summary` instead of the
`location` argument to checkSummaryTimestamp. If this call were to
overwrite the existing entry in the cache that would have resulted in us
using the old location of any module even if it was, say, moved to a
different directory between calls to 'depanal'.

However it turns out the cache just ignores the location if the module is
already in the cache. Since summariseModule has to search for the module,
which has the side effect of populating the cache, everything would have
been fine either way.

Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.