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
TcRnUselessTypeable
data constructor - Add and use
TcRnDerivingDefaults
data constructor - Add and use the
TcRnNonUnaryTypeclassConstraint
data constructor - Add and use
TcRnPartialTypeSignatures
- Add
T13324_compile2
test to test another part of theTcRnPartialTypeSignatures
diagnostic - Add and use
TcRnCannotDeriveInstance
data constructor, which introduces a new data constructor toTcRnMessage
calledTcRnCannotDeriveInstance
, which is further sub-divided to carry aDeriveInstanceErrReason
which explains the reason why we couldn't derive a typeclass instance. - Add
DerivErrSafeHaskellGenericInst
data constructor toDeriveInstanceErrReason
- Add
DerivErrDerivingViaWrongKind
andDerivErrNoEtaReduce
- Introduce the
SuggestExtensionInOrderTo
Hint, which adds (and use) a new constructor to the hint typeLanguageExtensionHint
calledSuggestExtensionInOrderTo
, 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 bothDeriveAnyClass
andGeneralizedNewtypeDeriving
. - Wildcard-free pattern matching in
mk_eqn_stock
, which removes_
in favour of pattern matching explicitly onCanDeriveAnyClass
andNonDerivableClass
, because that determine whether or not we can suggest to the userDeriveAnyClass
or not.