Strange over-liberal 'deriving' validity test
Currently GHC accepts an arbitrarily complicated IrredPred
in the context of a derived instance. E.g. here is test deriving/should_compile/T14339
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
Currently we get the derived instance
instance TypeError (Text "Boo") => Bar Baz
But is that really what we want? It defers the type error. Surely we should use standalone deriving if that is really what we want?
More generally, GHC.Tc.Validity.validDerivPred
has this code
validDerivPred tv_set pred
| not (tyCoVarsOfType pred `subVarSet` tv_set)
= False -- Check (VD3)
| otherwise
= case classifyPredType pred of
ClassPred cls tys -> ...
IrredPred {} -> True <-------------- YIKES!
EqPred {} -> False -- Reject equality constraints
ForAllPred {} -> False -- Rejects quantified predicates
This accepts an abitrarily complicated predicate, provided it's an IrredPred
like c blah blah
.
@rae and I think this is a bug, and we should tighten up validDerivPred
. I tripped over this in !7050 (merged), but I'm opening a ticket because fixing the bug could break some (obscure, probably wrong) programs.
@RyanGlScott maybe you'd like to look at this?