Type classes

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

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

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.
New testsuite verbosity level 4

which makes it print performance numbers even when the test succeeds
(good for historic analysis)
Give performance benchmark deviation also in percents

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%).
Partially revert 194107ea9333c1d9d61abf307db2da6a699847af

This reverts the numbers for T9203.

Signed-off-by: Austin Seipp <austin@well-typed.com>
Add a clarifying comment about scoping of type variables in associated type decls
White space only
Define PrelNames.allNameStrings and use it in TcHsType

Refactoring only.
Entirely re-jig the handling of default type-family instances (fixes Trac #9063)

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.
Improve documentation of :set/:seti

Prompted by Trac #9299
Improve documentation of overlapping instances (again)

Prompted by Trac #9288
Try to explain the applicativity problem

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Rewrite coercionRole. (#9233)

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
Optimise optCoercion. (#9233)

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.
Workaround haddock parser error caused by 5e7406d9

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>
Richards optCoercion improvement made test cases fail the nice way

This was likely caused by 5e7406d9, which fixed #9233.
Test Trac #9323
Include test case name in performance result

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.
Adjust a few performance numbers

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.