Skip to content
  • Ryan Scott's avatar
    25c02ea1
    Fix #16518 with some more kind-splitting smarts · 25c02ea1
    Ryan Scott authored and Marge Bot's avatar Marge Bot committed
    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.
    25c02ea1
    Fix #16518 with some more kind-splitting smarts
    Ryan Scott authored and Marge Bot's avatar Marge Bot committed
    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.
Loading