#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... 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