Fix #14916 with an additional validity check in deriveTyData
Manually-written instances and standalone-derived instances have the benefit of having the `checkValidInstHead` function run over them, which catches manual instances of built-in types like `(~)` and `Coercible`. However, instances generated from `deriving` clauses weren't being passed through `checkValidInstHead`, leading to confusing results as in #14916. `checkValidInstHead` also has additional validity checks for language extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up until now, GHC has never required these language extensions for `deriving` clause, so to avoid unnecessary breakage, I opted to suppress these language extension checks for `deriving` clauses, just like we currently suppress them for `SPECIALIZE instance` pragmas. Test Plan: make test TEST=T14916 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14916 Differential Revision: https://phabricator.haskell.org/D4501
Showing
- compiler/typecheck/TcDeriv.hs 8 additions, 1 deletioncompiler/typecheck/TcDeriv.hs
- compiler/typecheck/TcType.hs 2 additions, 0 deletionscompiler/typecheck/TcType.hs
- compiler/typecheck/TcValidity.hs 5 additions, 3 deletionscompiler/typecheck/TcValidity.hs
- testsuite/tests/deriving/should_fail/T14916.hs 8 additions, 0 deletionstestsuite/tests/deriving/should_fail/T14916.hs
- testsuite/tests/deriving/should_fail/T14916.stderr 10 additions, 0 deletionstestsuite/tests/deriving/should_fail/T14916.stderr
- testsuite/tests/deriving/should_fail/all.T 1 addition, 0 deletionstestsuite/tests/deriving/should_fail/all.T
Loading
Please register or sign in to comment