[GHC] #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon

[GHC]

#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