
#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