GitLab

To resolve ticket #11295, I think it makes sense to stop hard-coding
the pass sequences used by GHC when compiling with LLVM into the
compiler
itself.

This patchset introduces a companion to the existing `llvm-targets` file
called `llvm-passes`. The passes file is a simple association list that
holds the default LLVM `opt` pass sequence used by GHC. This allows end
users to easily save their favorite optimization flags when compiling
with LLVM.

The main benefit for ticket #11295 is that when adding a custom pass
sequence, it tends to be an extremely long string that would be
unsightly in the code.

This is essentially part 1 of 2 for ticket #11295.

Test Plan: ./validate

Reviewers: bgamari, angerman

Reviewed By: angerman

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4695

An attempt on #14975:
During compilation, reflexive casts is discarded for computation.
Currently in some places we use Maybe coercion as inputs. So if a cast
is reflexive it is denoted as Nothing, otherwise Just coercion.

This patch defines the type

data MCoercion = MRefl | MCo Coercion

which is isomorphic to Maybe Coercion but useful in a number of places,
and super-helpful documentation.

Test Plan: validate

Reviewers: bgamari, goldfire, simonpj

Reviewed By: goldfire

Subscribers: mpickering, rwbarton, thomie, carter

GHC Trac Issues: #14975

Differential Revision: https://phabricator.haskell.org/D4699

On 32-bit Linux `outofmem` did not fail with the expected out-of-memory
error message, instead failing with,

    outofmem: internal error: getMBlock: mmap: Invalid argument

This happened because, `my_mmap` would attempt to `madvise` even if the
`mmap` call failed. So while `mmap` returns `ENOMEM` we nevertheless try
to `madvise`, which clobbers `errno`, giving us the unexpected `EINVAL`
error. Consequently we don't detect this to be an out-of-memory error.

This should fix #15060.

Test Plan: `make test TEST=outofmem` on i386

Reviewers: simonmar, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15060

Differential Revision: https://phabricator.haskell.org/D4704

This ensures that the deferred type error can be emitted correctly.

For `main` function in `Main` module, we have

    :Main.main = GHC.TopHandler.runMainIO main

When the type of `main` is not `IO t` and the
`-fdefer-type-errors` is enabled, the `ev_binds`
of `main` function will contain deferred type
errors.

Previously, the `ev_binds` are bound to `runMainIO main`,
rather than `main`, the type error exception at runtime
cannot be handled properly. See Trac #13838.

This patch fix that.

Test Plan: make test TEST="T13838"

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #13838

Differential Revision: https://phabricator.haskell.org/D4708

Simon PJ recently fixed the problem behind this failure
so we can now expect this test to pass in all ways again.

The fixes got introduced in the following commits:
  86bba7d5
  d191db48

Test Plan: T14732 (profasm way)

Reviewers: bgamari, RyanGlScott, simonpj

Reviewed By: RyanGlScott, simonpj

Subscribers: simonpj, RyanGlScott, rwbarton, thomie, carter

GHC Trac Issues: #15163

Differential Revision: https://phabricator.haskell.org/D4725

Moving fingerprintByteString to GHC.Fingerprint would require
adding a dependency on bytestring to base.

Section 10.16 in the Users Guide. Also reviewed mentions/links from
other sections: none need revision.

Fixes #15146.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4735

Suppress warning about unused match.

Fixes #15187

Reviewers: bgamari, simonmar, erikd, hvr

Reviewed By: bgamari, simonmar

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4741

Namely armv6l-unknown-linux-gnueabihf and
armv7l-unknown-linux-gnueabihf.

Namely in T13719 and T13701.

When `readMVar` was implemented using `takeMVar` and `putMVar`,
we needed to use `modifyMVarMasked` in `readChan` just in case
the `readMVar` was interrupted between taking and putting. Now
that `readMVar` uses an atomic primop, this is impossible, so we can
safely unmask `readMVar`.

Reviewers: hvr, bgamari, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4738

Makes it possible to print STACK (StgStack) objects easily in gdb

Summary:
Another round and attempt at getting these down to 0.

We really should re-enable the CI and not wait for those cloud based ones.

I've disabled the backpack tests on windows as they are too broad, they test
as much the shell as they do the compiler.

The perf tests have been too long to track down. but the numbers are horrible
but I don't see them getting fixed so just have to accept them.

T9293 has new windows specific output because a Dyn way only flag was added.
This will of course not work on non-Dyn way builds.

Test Plan: ./validate

Reviewers: bgamari, hvr, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15107

Differential Revision: https://phabricator.haskell.org/D4668

Summary:
Fix a number of issues that have broken the 32 bit build.
This makes it build again.

Test Plan: ./validate

Reviewers: hvr, goldfire, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4691

Make it clear that max_live_bytes is updated after a major GC whereas
live_bytes is updated after all GCs (including minor collections) and
considers data in uncollected generations as live.

Reviewers: bgamari, simonmar, hvr

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4734

This data type witnesses the lifting of a monoid into an applicative
pointwise.

This appears to have been fixed at some point between GHC 8.0 and
8.2.

Commit 433b80de fixed #14172. Let's
add a regression test to ensure that it stays fixed.

Test Plan: Validate

Reviewers: int-index, osa1

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15038

Differential Revision: https://phabricator.haskell.org/D4723

This should have been part of D4477, but got missed.

Summary:
(re-applying this patch now that D4659 is committed)

Space leaks in GHCi emerge from time to time and tend to come back again
after they get fixed. This is an attempt to limit regressions by

* adding a reliable detection for some classes of space leaks in GHCi
* turning on leak checking for all GHCi tests in the test suite, so that
  we'll notice if the leak appears again.

The idea for detecting space leaks is quite simple:

* find some data that we expect to be GC'd later, make a weak pointer to it
* when we expect the data to be dead, do a `performGC` and then check
  the status of the weak pointer.

It would be nice to apply this trick to lots of things in GHC,
e.g. ensuring that HsSyn is not retained after the desugarer, or
ensuring that CoreSyn from the previous simplifier pass is not retained.

Test Plan: validate

Reviewers: bgamari, simonpj, erikd, niteria

Subscribers: thomie, carter

GHC Trac Issues: #15111

Summary:
The way we were pretty-printing conflicting data family
instances in an error message was far from ideal:

1. If a data type had no constructors, it would print an equals sign
   with nothing to the right of it.
2. It would try to print GADTs using Haskell98 syntax.
3. It eta-reduced away some type variables from the LHS.

This patch addresses these three issues:

1. We no longer print constructors at all in this error message.
   There's really no reason to do so in the first place, since
   duplicate data family instances always conflict, regardless of
   their constructors.
2. Since we no longer print constructors, we no longer have to
   worry about whether we're using GADT or Haskell98 syntax.
3. I've put in a fix to ensure that type variables are no longer
   eta-reduced away from the LHS.

Test Plan: make test TEST=T14179

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14179

Differential Revision: https://phabricator.haskell.org/D4711

Summary:
Template Haskell provides a wormhole through which you can
sneak methods that don't belong to a class into an instance for that
class, bypassing the renamer's validity checks. The solution adopted
here is to mirror the treatment for associated type family instances,
which have an additional check in the typechecker which catch
mismatched associated type families that were snuck through using
Template Haskell. I've put a similar check for class methods into
`tcMethods`.

Test Plan: make test TEST=T12387

Reviewers: bgamari, simonpj

Reviewed By: bgamari, simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #12387

Differential Revision: https://phabricator.haskell.org/D4710

Sadly I can't easily determine the cause of T13701's regression since the tree
was broken.

Unfortunately, this optimisation is infeasible on MachO platforms (e.g.
Darwin) due to an object format limitation. Specifically, linking fails
with errors of the form:

     error: unsupported relocation with subtraction expression, symbol
     '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be
     undefined in a subtraction expression

Apparently MachO does not permit relocations' subtraction expressions to
refer to undefined symbols. As far as I can tell this means that it is
essentially impossible to express an offset between symbols living in
different compilation units. This means that we lively can't use this
optimisation on MachO platforms.

Test Plan: Validate on Darwin

Reviewers: simonmar, erikd

Subscribers: rwbarton, thomie, carter, angerman

GHC Trac Issues: #15169

Differential Revision: https://phabricator.haskell.org/D4715