[GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932

GHC ghc-devs at haskell.org
Tue Mar 1 10:41:01 UTC 2016


#11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932
-------------------------------------+-------------------------------------
        Reporter:  thomie            |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:  TypeInType
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 simonpj):

 > Ah -- so the meta-tyvars aren't making it to the real `TyCon`, only the
 `TcTyCon`? It's quite normal for `TcTyCon`s to have meta-tyvars. (Indeed,
 that's what they're for.)

 Yes if they are a bare meta-tyvar, but not if they are full polymorphic
 kind gotten from a CUSK.  The whole point about being "complete" is that
 the signature is fully defined.  We experimented with partially-defined
 signatures and backed off. Complete means complete, and that means no
 lurking unification variables.

 > But I'm missing some context. The ASSERT that's breaking is the check
 during substitutions. But which substitution? I don't see an obvious
 substitution in `getFamDeclInitialKind`.

 It happens during the immediately following `tc_lhs_type`; at an
 occurrence of `MComp` we find that it has a polymorphic kind and try to
 instantiate that kind. The instantiation fails with this error.  (But it's
 just a canary in the mine; the real problem is that unification variable
 lurking in an allegedly-complete signature.

 So yes, (2) is the issue at hand.  To go back to your example:
 {{{
 data T (a :: Proxy k)
 }}}
 If we are to treat this as a CUSK (and I think we should) we must fix (at
 that very moment) the kind of `k`.  Fixing it to `*` is fine, although its
 a kind-of-arbitrary choice.  But fix it we must.  I think the place may be
 in `kcHsTyVarBndrs`, which I do not fully understand.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11648#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list