validDerivPred: Reject exotic constraints in IrredPreds

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, 25 insertions, 0 deletions

diff --git a/testsuite/tests/deriving/should_fail/T14339.hs b/testsuite/tests/deriving/should_fail/T14339.hs
new file mode 100644
index 0000000000..b48f2e2501
--- /dev/null
+++ b/testsuite/tests/deriving/should_fail/T14339.hs
@@ -0,0 +1,25 @@
+{-# LANGUAGE DataKinds #-}
+{-# LANGUAGE GeneralizedNewtypeDeriving #-}
+{-# LANGUAGE UndecidableInstances #-}
+module Bug where
+
+import GHC.TypeLits
+
+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
+
+-- We derive:
+--
+--  instance TypeError (Text "Boo") => Bar Baz
+--
+-- And error out due to the TypeError. See also
+-- deriving/should_compile/T22696a, which uses StandaloneDeriving to write a
+-- valid instance with a TypeError constraint in its instance context.