Rewrite `Coercible` solver

Summary:
This is a rewrite of the algorithm to solve for Coercible "instances".

A preliminary form of these ideas is at
https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver

The basic idea here is that the `EqPred` constructor of `PredTree`
now is parameterised by a new type `EqRel` (where
`data EqRel = NomEq | ReprEq`). Thus, every equality constraint can
now talk about nominal equality (the usual case) or representational
equality (the `Coercible` case).

This is a change from the previous
behavior where `Coercible` was just considered a regular class with
a special case in `matchClassInst`.

Because of this change, representational equalities are now
canonicalized just like nominal ones, allowing more equalities
to be solved -- in particular, the case at the top of #9117.

A knock-on effect is that the flattener must be aware of the
choice of equality relation, because the inert set now stores
both representational inert equalities alongside the nominal
inert equalities. Of course, we can use representational equalities
to rewrite only within another representational equality --
thus the parameterization of the flattener.

A nice side effect of this change is that I've introduced a new
type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness
in the flattener.

This commit includes some refactoring as discussed on D546.
It also removes the ability of Deriveds to rewrite Deriveds.

This fixes bugs #9117 and #8984.

Reviewers: simonpj, austin, nomeata

Subscribers: carter, thomie

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

GHC Trac Issues: #9117, #8984

1 files changed, 6 insertions, 8 deletions

diff --git a/testsuite/tests/deriving/should_fail/T1496.stderr b/testsuite/tests/deriving/should_fail/T1496.stderr
index 867d6c6842..c9f3869846 100644
--- a/testsuite/tests/deriving/should_fail/T1496.stderr
+++ b/testsuite/tests/deriving/should_fail/T1496.stderr
@@ -1,11 +1,9 @@
 
 T1496.hs:10:32:
-    Could not coerce from ‘c Int’ to ‘c Moo’
-      because ‘c Int’ and ‘c Moo’ are different types.
-      arising from the coercion of the method ‘isInt’ from type
-                   ‘forall (c :: * -> *). c Int -> c Int’ to type
-                   ‘forall (c :: * -> *). c Int -> c Moo’
-    Possible fix:
-      use a standalone 'deriving instance' declaration,
-        so you can specify the instance context yourself
+    Couldn't match representation of type ‘c Int’ with that of ‘c Moo’
+    arising from the coercion of the method ‘isInt’
+      from type ‘forall (c :: * -> *). c Int -> c Int’
+        to type ‘forall (c :: * -> *). c Int -> c Moo’
+    NB: We cannot know what roles the parameters to ‘c’ have;
+      we must assume that the role is nominal
     When deriving the instance for (IsInt Moo)