Implement stopgap solution for #14728
It turns out that one can produce ill-formed Core by combining `GeneralizedNewtypeDeriving`, `TypeInType`, and `TypeFamilies`, as demonstrated in #14728. The root of the problem is allowing the last parameter of a class to appear in a //kind// of an associated type family, as our current approach to deriving associated type family instances simply doesn't work well for that situation. Although it might be possible to properly implement this feature today (see https://ghc.haskell.org/trac/ghc/ticket/14728#comment:3 for a sketch of how this might work), there does not currently exist a performant implementation of the algorithm needed to accomplish this. Until such an implementation surfaces, we will make this corner case of `GeneralizedNewtypeDeriving` an error. Test Plan: make test TEST="T14728a T14728b" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14728 Differential Revision: https://phabricator.haskell.org/D4402 (cherry picked from commit 1ede46d4)
Showing
- compiler/typecheck/TcDeriv.hs 40 additions, 3 deletionscompiler/typecheck/TcDeriv.hs
- testsuite/tests/deriving/should_fail/T14728a.hs 20 additions, 0 deletionstestsuite/tests/deriving/should_fail/T14728a.hs
- testsuite/tests/deriving/should_fail/T14728a.stderr 7 additions, 0 deletionstestsuite/tests/deriving/should_fail/T14728a.stderr
- testsuite/tests/deriving/should_fail/T14728b.hs 16 additions, 0 deletionstestsuite/tests/deriving/should_fail/T14728b.hs
- testsuite/tests/deriving/should_fail/T14728b.stderr 7 additions, 0 deletionstestsuite/tests/deriving/should_fail/T14728b.stderr
- testsuite/tests/deriving/should_fail/all.T 2 additions, 0 deletionstestsuite/tests/deriving/should_fail/all.T
Loading
Please register or sign in to comment