#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