[GHC] #13738: TypeApplications-related GHC internal error

[GHC]

#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