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

2 Mar 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 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