Skip to content

Convert usages of `TcRnUnknownMessage` in `GHC.Tc.Deriv`

Alfredo Di Napoli requested to merge wip/adinapoli-issue-20119-part-2 into master

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 the TcRnPartialTypeSignatures diagnostic
  • Add and use TcRnCannotDeriveInstance data constructor, which introduces a new data constructor to TcRnMessage called TcRnCannotDeriveInstance, which is further sub-divided to carry a DeriveInstanceErrReason which explains the reason why we couldn't derive a typeclass instance.
  • Add DerivErrSafeHaskellGenericInst data constructor to DeriveInstanceErrReason
  • Add DerivErrDerivingViaWrongKind and DerivErrNoEtaReduce
  • Introduce the SuggestExtensionInOrderTo Hint, which adds (and use) a new constructor to the hint type LanguageExtensionHint called SuggestExtensionInOrderTo, 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 the DerivingStrategies, which automatically follows from having enabled both DeriveAnyClass and GeneralizedNewtypeDeriving.
  • Wildcard-free pattern matching in mk_eqn_stock, which removes _ in favour of pattern matching explicitly on CanDeriveAnyClass and NonDerivableClass, because that determine whether or not we can suggest to the user DeriveAnyClass or not.
Edited by Alfredo Di Napoli

Merge request reports