Re: [GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans

25 Mar 2015


      #9780: dep_orphs in Dependencies redundantly records type family orphans
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                   Owner:
            Type:  bug               |                  Status:  closed
        Priority:  normal            |               Milestone:  7.10.1
       Component:  Compiler          |                 Version:  7.9
      Resolution:  fixed             |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by thomie):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:   => 7.10.1


Comment:

 You updated that comment in commit
 4c834fdddf4d44d12039da4d6a2c63a660975b95:
 {{{
 Author: Edward Z. Yang <>
 Date:   Mon Nov 17 21:23:52 2014 -0800

     Filter instance visibility based on set of visible orphans, fixes
 #2182.

     Summary:
     Amazingly, the fix for this very old bug is quite simple: when type-
 checking,
     maintain a set of "visible orphan modules" based on the orphans list
 of
     modules which we explicitly imported.  When we import an instance and
 it
     is an orphan, we check if it is in the visible modules set, and if
 not,
     ignore it.  A little bit of refactoring for when orphan-hood is
 calculated
     happens so that we always know if an instance is an orphan or not.

     For GHCi, we preinitialize the visible modules set based on the list
 of
     interactive imports which are active.

     Future work: Cache the visible orphan modules set for GHCi, rather
 than
     recomputing it every type-checking round.  (But it's tricky what to do
 when you
     /remove/ a module: you need a data structure a little more complicated
 than
     just a set of modules.)

     Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

     Test Plan: new tests and validate

     Reviewers: simonpj, austin

     Subscribers: thomie, carter

     Differential Revision: https://phabricator.haskell.org/D488

     GHC Trac Issues: #2182
 }}}

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