[GHC] #15142: GHC HEAD regression: tcTyVarDetails

[GHC]

#15142: GHC HEAD regression: tcTyVarDetails
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  goldfire
            Type:  bug               |               Status:  merge
        Priority:  highest           |            Milestone:  8.6.1
       Component:  Compiler (Type    |              Version:  8.5
  checker)                           |             Keywords:  TypeInType,
      Resolution:                    |  TypeFamilies, CUSKs
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Compile-time      |            Test Case:  indexed-
  crash or panic                     |  types/should_compile/T15142
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > In 030211d2/ghc:

 Richard, I like this.  The code is simpler, `kcLHsQTyVars` has a simpler
 signature.  All good.

 But you did not respond to these points from comment:5:

 * First, `C` has a CUSK.  But does `T`?  Well `hsDeclHasCusk` reports True
 for the class decl, without even looking at `T`.  This seems wrong.

   What is the CUSK status of `T`?  Apparently `famDeclHasCusk` returns
 True if the enclosing class has a CUSK, but is that right?  There's a
 comment "all un-associated open families have CUSKs" which I don't
 understand.

   Ah... I see from [http://downloads.haskell.org/~ghc/master/users-
 guide/glasgow_exts.html#complete-user-supplied-kind-signatures-and-
 polymorphic-recursion the manual] that we treat open families as CUSK-ish
 by defaulting.  We should have a Note to explain the rules -- or I suppose
 a Note that summarises and points clearly to the manual as the reference.
 But why do we default here? It seems inconsistent with (say) `data T a b =
 ...`. Is it just an arbitrary choice of convenience?  What about `type
 family F (a :: k1 k2) :: *`?

 * `C` has a CUSK, but in `class C (a :: Type) (b :: k)`, I'm not sure how
 we get to know that `k :: Type`.   Yet, without that `C` would not have a
 CUSK.

   I guess that we are defaulting kind variables to `*`?  Well not to `*`,
 because we might have `class C (a :: k1 k2) where ...`

 After typing this in I realise that all I'm seeking is a clearer
 exposition of the CUSK rules.

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