[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 Simon Peyton Jones <simonpj@…>):

 In [changeset:"184a569c5f5fe6e2eed73b2cff35722918c44efd/ghc"
 184a569c/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="184a569c5f5fe6e2eed73b2cff35722918c44efd"
 Clean up TcHsSyn.zonkEnv

 Triggered by Trac #15552, I'd been looking at ZonkEnv in TcHsSyn.

 This patch does some minor refactoring

 * Make ZonkEnv into a record with named fields, and use them.
   (I'm planning to add a new field, for TyCons, so this prepares
   the way.)

 * Replace UnboundTyVarZonker (a higer order function) with the
   simpler and more self-descriptive ZonkFlexi data type, below.
  It's just much more perspicuous and direct, and (I suspect)
  a tiny bit faster too -- no unknown function calls.

 data ZonkFlexi   -- See Note [Un-unified unification variables]
   = DefaultFlexi    -- Default unbound unificaiton variables to Any
   | SkolemiseFlexi  -- Skolemise unbound unification variables
                     -- See Note [Zonking the LHS of a RULE]
   | RuntimeUnkFlexi -- Used in the GHCi debugger

 There was one knock-on effect in the GHCi debugger -- the
 RuntimeUnkFlexi case.  Somehow previously, these RuntimeUnk
 variables were sometimes getting SystemNames (and hence
 printed as 'a0', 'a1', etc) and sometimes not (and hence
 printed as 'a', 'b' etc).  I'm not sure precisely why, but
 the new behaviour seems more uniform, so I just accepted the
 (small) renaming wibbles in some ghci.debugger tests.

 I had a quick look at perf: any changes are tiny.
 }}}

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