validDerivPred: Reject exotic constraints in IrredPredswip/T22696

This brings the `IrredPred` case in sync with the treatment of `ClassPred`s as
described in `Note [Valid 'deriving' predicate]` in `GHC.Tc.Validity`. Namely,
we should reject `IrredPred`s that are inferred from `deriving` clauses whose
arguments contain other type constructors, as described in `(VD2) Reject exotic
constraints` of that Note.  This has the nice property that `deriving` clauses
whose inferred instance context mention `TypeError` will now emit the type
error in the resulting error message, which better matches existing intuitions
about how `TypeError` should work.

While I was in town, I noticed that much of `Note [Valid 'deriving' predicate]`
was duplicated in a separate `Note [Exotic derived instance contexts]` in
`GHC.Tc.Deriv.Infer`. I decided to fold the latter Note into the former so that
there is a single authority on describing the conditions under which an
inferred `deriving` constraint can be considered valid.

This changes the behavior of `deriving` in a way that existing code might
break, so I have made a mention of this in the GHC User's Guide. It seems very,
very unlikely that much code is relying on this strange behavior, however, and
even if there is, there is a clear, backwards-compatible migration path using
`StandaloneDeriving`.

Fixes #22696.

1 files changed, 26 insertions, 0 deletions

diff --git a/docs/users_guide/9.8.1-notes.rst b/docs/users_guide/9.8.1-notes.rst
index 352e0689ce..a624eb2705 100644
--- a/docs/users_guide/9.8.1-notes.rst
+++ b/docs/users_guide/9.8.1-notes.rst
@@ -61,6 +61,32 @@ Compiler
   The point is that only the type S has a constructor with both fields "foo"
   and "bar", so this record update is unambiguous.
 
+- Data types with ``deriving`` clauses now reject inferred instance contexts
+  that mention ``TypeError`` constraints (see :ref:`custom-errors`), such as
+  this one: ::
+
+      newtype Foo = Foo Int
+
+      class Bar a where
+        bar :: a
+
+      instance (TypeError (Text "Boo")) => Bar Foo where
+        bar = undefined
+
+      newtype Baz = Baz Foo
+        deriving Bar
+
+  Here, the derived ``Bar`` instance for ``Baz`` would look like this: ::
+
+      instance TypeError (Text "Boo") => Bar Baz
+
+  While GHC would accept this before, GHC 9.8 now rejects it, emitting "``Boo``"
+  in the resulting error message. If you really want to derive this instance and
+  defer the error to sites where the instance is used, you must do so manually
+  with :extension:`StandaloneDeriving`, e.g. ::
+
+      deriving instance TypeError (Text "Boo") => Bar Baz
+
 GHCi
 ~~~~