Convert usages of `TcRnUnknownMessage` in `GHC.Tc.Deriv`
This is part 2 of #20119 (closed), i.e. the ongoing effort of porting some TcRnUnknownMessage into proper data constructors, in various modules.
This (big) MR finishes porting the GHC.Tc.Deriv module to support the new diagnostic infrastructure (#18516) by getting rid of the legacy calls to TcRnUnknownMessage. This work ended up being quite pervasive and touched not only the Tc.Deriv module but also the Tc.Deriv.Utils and Tc.Deriv.Generics module, which needed to be adapted to use the new
infrastructure. This also required generalising Validity.
More specifically, this is a breakdown of the work done:
- Add and use the
TcRnUselessTypeabledata constructor - Add and use
TcRnDerivingDefaultsdata constructor - Add and use the
TcRnNonUnaryTypeclassConstraintdata constructor - Add and use
TcRnPartialTypeSignatures - Add
T13324_compile2test to test another part of theTcRnPartialTypeSignaturesdiagnostic - Add and use
TcRnCannotDeriveInstancedata constructor, which introduces a new data constructor toTcRnMessagecalledTcRnCannotDeriveInstance, which is further sub-divided to carry aDeriveInstanceErrReasonwhich explains the reason why we couldn't derive a typeclass instance. - Add
DerivErrSafeHaskellGenericInstdata constructor toDeriveInstanceErrReason - Add
DerivErrDerivingViaWrongKindandDerivErrNoEtaReduce - Introduce the
SuggestExtensionInOrderToHint, which adds (and use) a new constructor to the hint typeLanguageExtensionHintcalledSuggestExtensionInOrderTo, which can be used to give a bit more "firm" recommendations when it's obvious what the required extension is, like in the case for theDerivingStrategies, which automatically follows from having enabled bothDeriveAnyClassandGeneralizedNewtypeDeriving. - Wildcard-free pattern matching in
mk_eqn_stock, which removes_in favour of pattern matching explicitly onCanDeriveAnyClassandNonDerivableClass, because that determine whether or not we can suggest to the userDeriveAnyClassor not.