diff options
author | Alfredo Di Napoli <alfredo@well-typed.com> | 2021-09-20 15:51:21 +0200 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2021-10-05 14:34:04 -0400 |
commit | ac275f4237f1e4030c8b7b9e81e2d563e6903a81 (patch) | |
tree | 25786972e31bb6490b0558ee07d257d3135f3cb7 /testsuite/tests/typecheck/bug1465 | |
parent | f52df067d288a023c52c4387841fe12a37bd1263 (diff) | |
download | haskell-ac275f4237f1e4030c8b7b9e81e2d563e6903a81.tar.gz |
Eradicate TcRnUnknownMessage from GHC.Tc.Deriv
This (big) commit 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.
Diffstat (limited to 'testsuite/tests/typecheck/bug1465')
0 files changed, 0 insertions, 0 deletions