diff options
author | Ryan Scott <ryan.gl.scott@gmail.com> | 2023-03-22 09:06:31 -0400 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2023-04-17 18:43:27 -0400 |
commit | 0158c5f10869f567091c4f0cd9b127c0dc5cc413 (patch) | |
tree | 2af42abea28a49d0795f3a785d237a2156342b71 /compiler/GHC/Data | |
parent | 1532a8b2b222fee73959a0760ac8867be7f19ce6 (diff) | |
download | haskell-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 'compiler/GHC/Data')
0 files changed, 0 insertions, 0 deletions