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

[GHC]

#13738: TypeApplications-related GHC internal error
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        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):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Oh dear, I think I've been operating under a misconception in trying to
 debug this issue. I was originally under the impression that when renaming
 the expression `coerce @(forall (a :: k). f a)`, we would implicitly bind
 the `k` in the `forall` type (i.e., it would become something like `coerce
 @(forall k (a :: k). f @k a)`. However, this is decidedly //not// the case
 --as the
 [http://git.haskell.org/ghc.git/blob/1cdceb9fa3bc3ad01b2d840caad8e735513e14ed:/compiler/hsSyn/HsExpr.hs#l324
 Haddocks] for `HsAppType` reveal, we use `LHsWcType` for representing a
 visible type argument, precisely because it can have wildcards but //not//
 implicit quantification.

 In light of this, I think that the original program should actually give a
 `"Not in scope: type variable 'k'"` error. But there's a problem:
 `bindLHsTyVarBndr` //always// attempts to implicitly bind any free kind
 variables in `forall`'d type variables' kind signatures. As a result, `k`
 never gets reported as out-of-scope after renaming (which would be the
 ideal way to catch this).

 What is the best way to detect this scenario, then? We could add a `Bool`
 argument to `bindLHsTyVarBndr` that controls whether it attempts to
 implicitly bind free kind variables or not. But this feels like a heavy
 approach, since we'd be tweaking the behavior of a very widely used
 function in renamer (and causing a lot of replumbing) only to account for
 `LHsWcType`, something which AFAICT is really only used in one particular
 place: visible type application. But I'm not aware of a more clever way to
 address this.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13738#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler