#10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Let's talk about recompilation avoidance and how the user-facing interface for fat interfaces work. Ideally, compilation to a fat interface (`-fno-code -fwrite-fat- interface`) should be similar to compilation to an interface (`-fno-code `-fwrite-interface`), including recompilation avoidance. This includes the following properties: 1. Incremental compile. If `A` imports `B`, and I've built `B.hi-fat`, I should also be able to build `A.hi-fat`. (This implies that an `hi-fat` file should be loadable to get `TyThing`s.) 2. If I build `A.hi-fat`, and then modify `A.hs`, if I ask GHC to build `A .hi-fat` again, it should be rebuilt; similarly if the `TyThing`s of any of its dependencies changed. However, if there are no changes, I shouldn't have to rebuild `A.hi-fat`. 3. If I am compiling an `A.hi-fat` to `A.o` and `A.hi` (e.g. finishing the compilation), it's unreasonable to expect GHC to handle the case where the `A.hi-fat` is out of date relative to the `A.hs` or any of its dependencies. However, if it is out of date, GHC should detect this and give an error, rather than generate some incorrect code. The mental model I have is that we can think of an `hi-fat` file as consisting of two parts: an types only `hi` file that would have been the result of an `-fno-code -fwrite-interface` (so, a properly Tidied interface that is good for typechecking and then loading in for later typechecking, but without any unfoldings) as well as the `fat` bits which can be used to reconstruct a `ModGuts` and finish compilation. (Of course, you'd really like this to all be ONE file. Should look at this carefully and make sure it works!) Importantly, we DON'T care about fingerprinting the bindings and stuff for compilation; only the typechecking information. We have to be careful not to confuse `hi` files and `hi-fat` files in GHC. If I'm typechecking for an `hi-fat` file, I only want to preferentially use `hi-fat` files; however, if I'm actually building a module, I really want `hi` files (so I get the right unfoldings). We have a somewhat similar situation in Backpack: I really don't want the types only definitions polluting the EPT, because then things won't optimize. Here is where things get tricky, because when we typecheck a module and then desugar it, we are going to use the typecheck only `hi` files, but when we BUILD the ModGuts, we're going to want to use the actually built `hi` files. How do we tell if these are actually in sync? We're going to need some only "type-check" only hash which we can use to test for consistency. Hmm! ModIface should have something close to this already but we have to check. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10871#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler