#12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): It's buried a bit in all the text I wrote above (written when I was still trying to understand the code), but it's the line {{{ = do { (subst, tvs') <- newMetaTyVars tvs }}} of `deeplyInstantiate`, particularly inside the recursive call that happens a few lines down. {{{ ; (wrap2, rho2) <- deeplyInstantiate orig (substTyUnchecked subst rho) }}} In the example I give above there are two forall groups. The first works fine and substitutions are made into the second via the `substTyUnchecked`, in particular into the kind variables of the second group. However these kind variables are not part of the the in-scope set when {{{ kind = substTyUnchecked subst (tyVarKind tv) }}} is called in `new_meta_tv_x` of the second, recursive, call of `deeplyInstantiate`, since `newMetaTyVars ` starts with a fresh empty in- scope set, thus the panic I was looking at. As I noted above, the kind variables being substituted into are "fresh" from the outer call and thus there will be no real problem, but it's probably better to pass them in to `newMetaTyVars` as Richard suggests rather than trying to special-case the checking logic, and there may well still be places where not passing in a pre-existing in-scope set does cause a real problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12549#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler