[GHC] #15552: Infinite loop/panic with an existential type.

[GHC]

#15552: Infinite loop/panic with an existential type.
-------------------------------------+-------------------------------------
        Reporter:  howtonotwin       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:  TypeInType,
                                     |  TypeFamilies
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #14723            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 In unravelling #15552 I also realised that
 * `Note [Type checking recursive type and class declarations]` in
 `TcTyClsDecls` uses the global type envt during zonking to hold the knot-
 tied TyCons
 * But the `ZonkEnv` used in `TcHsSyn` plays a very, very similar role
 {{{
 data ZonkEnv
   = ZonkEnv
       UnboundTyVarZonker
       (TyCoVarEnv TyVar)
       (IdEnv      Var)         -- What variables are in scope
         -- Maps an Id or EvVar to its zonked version; both have the same
 Name
         -- Note that all evidence (coercion variables as well as
 dictionaries)
         --      are kept in the ZonkEnv
         -- Only *type* abstraction is done by side effect
         -- Is only consulted lazily; hence knot-tying
 }}}
 Moreover, as you'll see in `TcHsSyn.zonkRecMonoBinds`, the `ZonkEnv` is
 used in a knot-tied way, to get sharing of all the `Ids`.

 My thought: we should use the same mechanism for both.  The most
 straightforward thing is to add a `NameEnv TyCon` to `ZonkEnv` for those
 knot-tied `TyCons`.  Then, in `TcTyClDecls` insetad of
 {{{
   ; tcExtendRecEnv (zipRecTyClss tc_tycons rec_tyclss) $
     ...mapM (tcTyClDecl roles) tyclds...
 }}}
 we'd create a `ZonkEnv`, and pass it into `tcTyClDecl`.  A little bit more
 plumbing,
 but more honest and certainly more uniform.

 PS: it must be possible to get rid of that `UnboundTyVarZonker` field too.

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