[GHC] #12549: Panic on ":t datatypeName"

[GHC]

#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