#13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Phab:D3873 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I disagree. The `RnTyiEnv` is pushed in recursively; and `bindLHsTyVarBndrs` is used at every nested forall. But that's '''not''' what we want to kind-variable scoping. We only add implicit kind variable binders at the top level of a type signature `LHsSigWcType`. We should not be adding any implicit kind-variable bindings at nested foralls. So * `bindLHsTyVarBndrs` has no business binding implicit kind variables at all! It should not be given an argument `kvs`. (Indeed that argument is empty when `bindLHsTyVarBndrs` is invoked by nested foralls.) * `bindLHsTyVarBndr` should not be calling `bindImplicitKvs` (as it does now). Those kvs should already be in scope, brought into socpe by `rn_hs_sig_wc_type` or `rnHsSigType`. * Instead, `bindHsQTyVars` should call `rnImplicitBndrs` on the passed-in `kv_bndrs`, just as `rn_hs_sig_wc_type` does. Getting rid of this will simplify `bindLhsTyVarBndrs`. And once we have done this, the `k` will simply be reported as out of scope. Does that make sense? Care to have a go? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13738#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler