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

[GHC]

#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 goldfire):

 Replying to [comment:17 simonpj]:
 > > So, I must ask: why is it so necessary to have the INVARIANT at the
 top?
 >
 > What if `f :: forall k. forall (a :: kappa). blah`, where `kappa` is a
 kind meta-var.  What if `kappa` was later instantiated to `k`?  Now the
 type looks quite different.

 I'm not sure what you mean by "quite different". Yes, if we get `kappa :=
 k`, then the type has more dependency, but what's so bad about that?

 >
 > Indeed `kcHsTyVarBndrs` goes to some trouble to avoid this
 > {{{
 >               -- in the CUSK case, we want to default any un-kinded
 tyvars
 >               -- See Note [Complete user-supplied kind signatures] in
 HsDecls
 >            ; case hs_tvb of
 >                UserTyVar {}
 >                  | cusk
 >                  , not scoped  -- don't default class tyvars
 >                  -> discardResult $
 >                     unifyKind (Just (mkTyVarTy tv)) liftedTypeKind
 >                                                     (tyVarKind tv)
 > }}}

 This code is intended to deal with open data/type family declarations,
 which always have a CUSK, by fiat. It shouldn't trigger in any other case,
 because all other declaration forms require `KindedTyVar`s to make a CUSK.

 > For your T1/T2 example I'm not too bothered.  CUSKs mean that the user
 has ''specified the complete kind''.  If you want `k` to have some other
 kind than `*` you can specify that too (I hope).

 OK.

 >
 > For T3/T4, note that `kdHsTyVarBndrs` calls `TcHsTyVarBndr_Scoped` which
 in turn calls `unifyKind` so I think you'll be fine.  (BUt there is
 clearly a missing `solveEqualities` here!

 Yes, I suppose that's true.

 But I don't spot a missing `solveEqualities` anywhere. Did you miss the
 call toward the top of `kcTyClGroup`?

 Bottom line here: I'm unconvinced about INVARIANT. But it does seem easy
 enough to implement "all declarations with CUSKs default all meta-tyvars",
 which solves the main problem here. And then we just punt on INVARIANT. In
 other words, I wish to address (1) from comment:14, which will then solve
 (2) on the way.

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