[GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules

[GHC]

#10270: inconsistent semantics of type class instance visibility outside recursive
modules
-------------------------------------+-------------------------------------
        Reporter:  skilpat           |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  MacOS X           |            Architecture:  x86_64
 Type of failure:  GHC rejects       |  (amd64)
  valid program                      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by ezyang):

 This is probably due to the retypecheck loop:

 {{{
 See bug #930.  This code fixes a long-standing bug in --make.  The
 problem is that when compiling the modules *inside* a loop, a data
 type that is only defined at the top of the loop looks opaque; but
 after the loop is done, the structure of the data type becomes
 apparent.

 The difficulty is then that two different bits of code have
 different notions of what the data type looks like.

 The idea is that after we compile a module which also has an .hs-boot
 file, we re-generate the ModDetails for each of the modules that
 depends on the .hs-boot file, so that everyone points to the proper
 TyCons, Ids etc. defined by the real module, not the boot module.
 Fortunately re-generating a ModDetails from a ModIface is easy: the
 function TcIface.typecheckIface does exactly that.

 Picking the modules to re-typecheck is slightly tricky.  Starting from
 the module graph consisting of the modules that have already been
 compiled, we reverse the edges (so they point from the imported module
 to the importing module), and depth-first-search from the .hs-boot
 node.  This gives us all the modules that depend transitively on the
 .hs-boot module, and those are exactly the modules that we need to
 re-typecheck.

 Following this fix, GHC can compile itself with --make -O2.
 }}}

 As a side effect, the instances also get dragged in. In one-shot mode, we
 use a different mechanism, the `tcg_type_env_var`, to ensure we can deal
 with the recursive case.

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