[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:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 Replying to [comment:94 goldfire]:
 > I have two takeaways from this:
 >
 > - An accumulator style is the Right Way to go when building up a set.
 This idea should probably be abstracted over right in the `VarSet`
 interface. But do we get these gains without eta-expanding everything?
 (See Note [FV eta expansion] in FV.)

 IIRC, I eta-reduced the relevant functions (`tyCoVarsOfXXXX`), but found
 no significant difference. I only did this for the `VarSet` approach
 though; I believe the reasoning in that note only holds for FV.

 Baking accumulator style into `VarSet` is logical, but if we do this, we
 also need to add the `in_scope` filtering thing found in `FV`, because, as
 the `nondet-no-in-scope` version shows, not doing this absolutely
 devastates performance. However, `VarSet` plus accumulator style is
 exactly `NDFV`, which is `FV` minus the list, which in turn makes no
 significant difference anyway. So effectively, this takeaway says we
 should be using `FV`.

 > - The extra work to track order has no effect. I find this surprising,
 but not overly so, because we can avoid the extra work via laziness.

 Well, when I wrote "no effect", I was actually lying a little bit -
 getting rid of the list reduces overall allocations by about 500 bytes.
 Which, I think, is about what you'd expect from removing something that
 never gets evaluated anyway.

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