#12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc4 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Yes. Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Urgh. I know what is going on here. The problem is that `Constrd` is bogus because its right-hand side is constrained and we haven't enabled the right extensions. The validity check fails. Regardless, GHC tries to continue to check the remaining declarations. To do this, GHC replaces `Constrd` with a stubbed-out `TyCon`, as explained in this note: {{{ {- Note [Recover from validity error] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We recover from a validity error in a type or class, which allows us to report multiple validity errors. In the failure case we return a TyCon of the right kind, but with no interesting behaviour (makeTyConAbstract). Why? Suppose we have type T a = Fun where Fun is a type family of arity 1. The RHS is invalid, but we want to go on checking validity of subsequent type declarations. So we replace T with an abstract TyCon which will do no harm. See indexed-types/should_fail/BadSock and Trac #10896 Painfully, though, we *don't* want to do this for classes. Consider tcfail041: class (?x::Int) => C a where ... instance C Int The class is invalid because of the superclass constraint. But we still want it to look like a /class/, else the instance bleats that the instance is mal-formed because it hasn't got a class in the head. -} }}} Because of the changes caused by `TypeInType`, the solver now can run while checking type declarations, and the solver ends up seeing the stubbed-out `TyCon`, causing the panic. What should be done about this? Here are some ideas: 1. Some up with a way to deal with the problem described in the Note without fully stubbing out the `TyCon`. For example, the bogus `T` in the note could be transmuted to a `type family T a` with no instances. 2. If there is a validity error in one mutually-recursive group, don't proceed to the next group. This will reduce the number of errors reported in one go. 3. Enlarge the stubbed-out `TyCon`s to be able to make it through the solver without panicking. This shouldn't be too hard, but it seems like the wrong direction of travel. In any case, I'm not assigning the ticket to myself, because I make no guarantees about my ability to finish this work. I just saw that `TcTyCon` (which is the current form of a stubbed-out `TyCon`) was causing trouble so I thought I'd take a look. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12083#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler