[GHC] #10871: Implement "fat" interface files which can be directly compiled without source

[GHC]

#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