[GHC] #14128: Possible bug in Renamer when dealing with orphans

[GHC]

#14128: Possible bug in Renamer when dealing with orphans
-------------------------------------+-------------------------------------
        Reporter:  Shayan-Najd       |                Owner:  bgamari
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.2.2
       Component:  Compiler (Type    |              Version:  8.2.1
  checker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 It seems like there is a bit of inconsistency regarding whether or not a
 module can be in its own `dep_orphs`. `TcRnDriver.tcRnImports` seems to
 suggest that `imp_orphs` (from which `DsUsage.mkDependencies` derives
 `dep_orphs`) can contain the current module due to `hs-boot`s,
 {{{#!hs
                 -- Load any orphan-module (including orphan family
                 -- instance-module) interfaces, so that their rules and
                 -- instance decls will be found.  But filter out a
                 -- self hs-boot: these instances will be checked when
                 -- we define them locally.
                 -- (We don't need to load non-orphan family instance
                 -- modules until we either try to use the instances they
                 -- define, or define our own family instances, at which
                 -- point we need to check them for consistency.)
         ; loadModuleInterfaces (text "Loading orphan modules")
                                (filter (/= this_mod) (imp_orphs imports))
 }}}

 However, the assertion in `RnNames.calculateAvails` (which is what Shayan
 reports) obvious disagrees:
 {{{#!hs
       orphans | orph_iface = ASSERT2( not (imp_sem_mod `elem` dep_orphs
 deps), ppr imp_sem_mod <+> ppr (dep_orphs deps) )
                              imp_sem_mod : dep_orphs deps
 }}}

 Looking at `mkDependendies`, it seems that we explicitly filter the
 currently module out of `imp_dep_mods`,
 {{{#!hs
       let dep_mods = modDepsElts (delFromUFM (imp_dep_mods imports)
                                            (moduleName mod))
                 -- M.hi-boot can be in the imp_dep_mods, but we must
 remove
                 -- it before recording the modules on which this one
 depends!
                 -- (We want to retain M.hi-boot in imp_dep_mods so that
                 --  loadHiBootInterface can see if M's direct imports
 depend
                 --  on M.hi-boot, and hence that we should do the hi-boot
 consistency
                 --  check.)
 }}}

 We do not do the same thing for `dep_orphs`; I wonder if this should
 change.

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