Fix #16518 with some more kind-splitting smarts
authorRyan Scott <ryan.gl.scott@gmail.com>
Tue, 2 Apr 2019 00:36:31 +0000 (20:36 -0400)
committerMarge Bot <ben+marge-bot@smart-cactus.org>
Thu, 4 Apr 2019 08:29:29 +0000 (04:29 -0400)
commit25c02ea172ef1dad2d12d8baff6ce57a68bf4127
tree6b1a044b85ecb82c2b7f1edaece878aec6a9098b
parent75abaaead796415cf2b5da610f4b3ee75b9d7759
Fix #16518 with some more kind-splitting smarts

This patch corrects two simple oversights that led to #16518:

1. `HsUtils.typeToLHsType` was taking visibility into account in the
   `TyConApp` case, but not the `AppTy` case. I've factored out the
   visibility-related logic into its own `go_app` function and now
   invoke `go_app` from both the `TyConApp` and `AppTy` cases.
2. `Type.fun_kind_arg_flags` did not properly split kinds with
   nested `forall`s, such as
   `(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply
   because `fun_kind_arg_flags`'s `FunTy` case always bailed out and
   assumed all subsequent arguments were `Required`, which clearly
   isn't the case for nested `forall`s. I tweaked the `FunTy` case
   to recur on the result kind.
compiler/hsSyn/HsUtils.hs
compiler/types/Type.hs
testsuite/tests/deriving/should_compile/T16518.hs [new file with mode: 0644]
testsuite/tests/deriving/should_compile/all.T