#13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): * comment:2: Sorry, I shouldn't have used this example, since it's not actually tripping up the `ASSERT`. In fact, it does close over the kinds of the type variables, which you can see by looking at the [http://git.haskell.org/ghc.git/blob/f656fba19d0cefe05643ddea35d080ea332a6584... definition of zipTvSubst]: {{{#!hs zipTvSubst :: [TyVar] -> [Type] -> TCvSubst zipTvSubst tvs tys | debugIsOn , not (all isTyVar tvs) || neLength tvs tys = pprTrace "zipTvSubst" (ppr tvs $$ ppr tys) emptyTCvSubst | otherwise = mkTvSubst (mkInScopeSet (tyCoVarsOfTypes tys)) tenv where tenv = zipTyEnv tvs tys }}} It uses `tyCoVarsOfTypes` to get the tyvars for the in-scope set, so they will include the necessary kind variables. Phew. * comment:3. Aha! What I should have done is split `substTyVar` into a checked version and an unchecked version, and use the unchecked version in `subst_ty` (`subst_ty` is already using `substTyVarBndrUnchecked` [http://git.haskell.org/ghc.git/blob/f656fba19d0cefe05643ddea35d080ea332a6584... here], so this doesn't make things any less palatable than before). I'll post an update after I've ran `./validate` with this change. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13959#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler