
#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