[GHC] #14759: ListSetOps WARNING causes tests to fail

[GHC]

#14759: ListSetOps WARNING causes tests to fail
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                Owner:  (none)
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4628
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 >  I think this can work, but we'd have to remove dups from A's imp_finsts
 before computing imp_finsts for B if B imports A. Otherwise for bigger
 module hierarchies a lot of duplicates will accumulate.

 Yes, the idea is to allow dups to accumulate (which happens for free, just
 by `unionBags`) and then when ''consuming'' the bag simply avoid doing
 things twice.  I think that's good, because generally we accumulate the
 `imp_fints` and then remove dups, sort, etc to make `dep_finists` for this
 module.  But this approach does depend on the "accumulate and consume
 once" pattern.

 > Perhaps we could avoid explicitly storing the whole transitive closure
 if when checking type family consistency we did a traversal with pruning
 instead

 Maybe so, but I'm not certain.  For sure you'd want to know whether a
 module had family instances either in itself or in its transitive imports.
 Let's call that the "finst flag" Then, to look for imported instances, you
 could say

 * For each imported module M, if its finst-flag is off, ignore M.
 * Otherwise, check for family instances in M, and then
 * Consider each direct import of M

 That'd require you to traverse a path of .hi files to get to the one with
 the family instances in it.  (Currently we can jump direct to the latter.)
 But perhaps that's fine.  Looks like a good thing to explore.

 We could do the same for orphan-instance modules.

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