#11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): This looks terribly suspicious (in `TyCoRep`): {{{ extendSubstEnvs :: (TvSubstEnv, CvSubstEnv) -> Var -> Type -> (TvSubstEnv, CvSubstEnv) extendSubstEnvs (tenv, cenv) v ty | isTyVar v = ASSERT( not $ isCoercionTy ty ) (extendVarEnv tenv v ty, cenv) -- NB: v might *not* be a proper covar, because it might be lifted. -- This happens in tcCoercionToCoercion | CoercionTy co <- ty = (tenv, extendVarEnv cenv v co) | otherwise = pprPanic "extendSubstEnvs" (ppr v <+> text "|->" <+> ppr ty) }}} I think that the `Var` passed to `extendSubsEnv` should be a proper `TyVar` or a `CoVar`. Moreover `tcCoercionToCoercion` doesn’t exist. Is the comment now out of date? I hope so. Moreover, it seems suspicious to pattern match on `CoercionTy`. What if there was a type synonym in the way? Or a cast? HOWEVER, we do need to get the coercion out to put into `cenv`. But that makes me suspicious too. I think that almost all calls to `extendSubstEnvs` provide only `TyVars`, not `CoVars`. The only call I can find that doesn’t is in `TcMType.instSkolTyCoVarX`, which tests the variable, and makes a `CoercionTy` – only for `extendTCvSubst` to unpack it again. Concretely, I suggest that * we rename `extendTCvSubst` to be `extendTvSubst`, and work only over `TyVars`. (Have an assertion of course.) * have a similar one for `extendCvSubst` and see how that goes. It’s be in line with the new `zipTvSubst`, `zipCvSubst` etc. Richard, can you see anything wrong with that? Bartosz, might you execute? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11371#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler