summaryrefslogtreecommitdiff
path: root/nofib
diff options
context:
space:
mode:
authorRyan Scott <ryan.gl.scott@gmail.com>2023-03-22 09:06:31 -0400
committerMarge Bot <ben+marge-bot@smart-cactus.org>2023-04-17 18:43:27 -0400
commit0158c5f10869f567091c4f0cd9b127c0dc5cc413 (patch)
tree2af42abea28a49d0795f3a785d237a2156342b71 /nofib
parent1532a8b2b222fee73959a0760ac8867be7f19ce6 (diff)
downloadhaskell-0158c5f10869f567091c4f0cd9b127c0dc5cc413.tar.gz
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.
Diffstat (limited to 'nofib')
0 files changed, 0 insertions, 0 deletions