[GHC] #14880: GHC panic: updateRole

[GHC]

#14880: GHC panic: updateRole
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  goldfire
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler (Type    |              Version:  8.2.2
  checker)                           |
      Resolution:                    |             Keywords:  TypeInType
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #15076            |  Differential Rev(s):  Phab:D4769,
       Wiki Page:                    |  Phab:D5141
-------------------------------------+-------------------------------------

Comment (by tdammers):

 So, let's see if I understand things correctly:

 - The original plan was to move the "closing over kinds" part out of
 `ty_co_vars_of_type`, and doing it in one go at the very end.
 - The new plan is to change `ty_co_vars_of_type` such that the
 "interesting" case (`TyVar` with a variable that hasn't been seen before)
 is handled in place, because the real problem is not about when we do the
 closing over kinds, but rather that we do not want to handle the same
 variable more than once.
 - Hence, we should not move the closing-over-kinds part at all, and
 instead just modify the `TyVar` branch of `ty_co_vars_of_type` so that it
 handles each variable it encounters exactly once (comment:123)

 I will certainly give that a try and see how that plays out in terms of
 performance.

 I had been implementing Simon's suggestion from comment:122, and at least
 while still using `mapUnionVarSet`, I'm still getting regressions on 4
 tests, so the hypothesis in comment:123 seems plausible to me - after all,
 if we can handle this correctly while already traversing the code, that's
 going to be more efficient than first building up the whole varset and
 then traversing it again to remove the variables we don't want.

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