Synchronize ClsInst.doTyConApp with TcTypeable validity checks (#15862)
authorRyan Scott <ryan.gl.scott@gmail.com>
Fri, 14 Jun 2019 15:07:46 +0000 (11:07 -0400)
committerMarge Bot <ben+marge-bot@smart-cactus.org>
Sun, 16 Jun 2019 03:35:03 +0000 (23:35 -0400)
commit25ee60cdae6ddedaf6b4677c6327c0f31c81073a
tree7cd719be751cda761613ac86ae8f11181e1b7a09
parent57b718481d5363ab33df4c7814f74897418f79d7
Synchronize ClsInst.doTyConApp with TcTypeable validity checks (#15862)

Issue #15862 demonstrated examples of type constructors on which
`TcTypeable.tyConIsTypeable` would return `False`, but the `Typeable`
constraint solver in `ClsInst` (in particular, `doTyConApp`) would
try to generate `Typeable` evidence for anyway, resulting in
disaster. This incongruity was caused by the fact that `doTyConApp`
was using a weaker validity check than `tyConIsTypeable` to determine
if a type constructor warrants `Typeable` evidence or not. The
solution, perhaps unsurprisingly, is to use `tyConIsTypeable` in
`doTyConApp` instead.

To avoid import cycles between `ClsInst` and `TcTypeable`, I factored
out `tyConIsTypeable` into its own module, `TcTypeableValidity`.

Fixes #15862.
compiler/ghc.cabal.in
compiler/typecheck/ClsInst.hs
compiler/typecheck/TcTypeable.hs
compiler/typecheck/TcTypeableValidity.hs [new file with mode: 0644]
testsuite/tests/typecheck/should_fail/T15862.hs [new file with mode: 0644]
testsuite/tests/typecheck/should_fail/T15862.stderr [new file with mode: 0644]
testsuite/tests/typecheck/should_fail/all.T