Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This equality-floating stuff is horribly delicate!  Trac #9316 showed
up yet another corner case.

The main changes are
 * include CTyVarEqs when "growing" the skolem set
 * do not include the kind argument to (~) when growing the skolem set

I added a lot more comments as well

With CPU=3 we are hitting resoure limits (probably memory). With CPU=2
this is less likely to happen. We will get more random timeouts, but
these are more easily spotted, and marked as "Failure", not as "Error".

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

These did not yet trigger a failure, but are more than 1% away from the
expected value. Since I now start collecting logs to investigate
deviations from the expected value, it makes sense to reset them. This
way we know that every significat deviation was caused since this
commit.

I only updated bytes_allocated numbers, as these are (mostly)
deterministic. Other depend, AFAIK, on sampling timing, so I did not
bother.

With THREADS=n, for n > 1, it becomes impossible to match the
performance numbers to the test case name. Hence include it in the
output. This also makes grepping through a bunch of logs for a specific
test case much easier, and outweighs the extra verbosity.

This was likely caused by 5e7406d9, which fixed #9233.

Haddock complains if a comment looks like a misplaced Haddock-comment.
In this case, the comment line starting with `-- *kind* and` looked like a
section-heading to Haddock and caused the following error:

    parse error on input ‘-- *kind* and role of its argument. Luckily, laziness should’

This commit just rewraps the line so that no `*` appear at the start of the
non-Haddock comment lines.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

The old optCoercion (and helper functions) used coercionKind and
coercionRole internally. This was terrible when these had to be
called at *every* point in the coercion tree during the recursive
descent. This is rewritten to avoid such calls.

Summary:
coercionRole is now much more efficient, computing both the coercion's
kind and role together. The previous version calculated them separately,
leading to quite possibly exponential behavior.

This is still too slow, but it's a big improvement.

Test Plan: Evaluate by running the "minimized" test from the Trac ticket.

Reviewers: simonpj, austin

Subscribers: simonmar, relrod, carter

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

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Prompted by Trac #9288

Prompted by Trac #9299

In looking at Trac #9063 I decided to re-design the default
instances for associated type synonyms.  Previously it was all
jolly complicated, to support generality that no one wanted, and
was arguably undesirable.

Specifically

* The default instance for an associated type can have only
  type variables on the LHS.  (Not type patterns.)

* There can be at most one default instances declaration for
  each associated type.

To achieve this I had to do a surprisingly large amount of refactoring
of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
of the LHS patterns.

That change in HsDecls has a (trivial) knock-on effect in Haddock, so
this commit does a submodule update too.

The net result is good though.  The code is simpler; the language
specification is simpler.  Happy days.

Trac #9263 and #9264 are thereby fixed as well.

Refactoring only.

This reverts the numbers for T9203.

Signed-off-by: Austin Seipp <austin@well-typed.com>

this makes it easier to spot a “just over the mark” change (e.g. +5.1%),
compared to a more radical jump (e.g. +15%).

which makes it print performance numbers even when the test succeeds
(good for historic analysis)

I started monitoring perfomance on a per-commit base. These seem to be
off for a while now. Adjusting them, and from now I hope I can keep
closer tabs on them.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Summary:
this set of patches adds support for x86_64-solaris2 platform
Solaris is multi-lib platform which means it provides 32bit user-land together
with 32bit and 64bit libraries. The 32bit libraries are located in <somewhere>/lib
directories while 64bit libraries are located in <somewhere>/lib/64 directories.
This is why GHCi required the fix since otherwise it'll attempt to load
/usr/lib/libgmp.so which is 32bit library into 64bit binary process space (GHCi).
This of course fails with wrong ELFCLASS32 error message.
Another issue was that by default GNU C distributed with Solaris compiles
into 32bit binary. We need to enforce compilation to 64bit binary
by adding appropriate -m64 option.

Test Plan: already built on x86_64-solaris2

Reviewers: austin

Reviewed By: austin

Subscribers: phaskell, simonmar, relrod, carter

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

Summary: (for the same reason that we acquire all the other mutexes)

Test Plan: validate

Reviewers: simonmar, austin, duncan

Reviewed By: simonmar, austin, duncan

Subscribers: simonmar, relrod, carter

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

Summary: Documented in more detail inline with the change.

Test Plan: validate

Reviewers: austin, simonmar, duncan

Reviewed By: austin, simonmar, duncan

Subscribers: simonmar, relrod, carter

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

Summary:
Currently, if the same identifier is imported via multiple modules, ghci
shows multiple completions for it. Use the nub of the completions
instead so that it only shows up once.

Signed-off-by: Shachaf Ben-Kiki <shachaf@gmail.com>

Test Plan: by hand

Reviewers: simonmar, austin, hvr

Reviewed By: austin, hvr

Subscribers: hvr, simonmar, relrod, carter

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

Auditors: hvr

Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
This should fix the Harbormaster builds; the bounds are just a little too narrow.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Harbormaster should build successfully.

Reviewers: simonmar

Subscribers: phaskell, simonmar, relrod, carter

Projects: #ghc

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