[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 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.

 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)
 }}}
 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).

 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!

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