Save merged signatures to disk

The Backpack model of development encourages users to mix signatures together. For example:

unit p where
  signature H where x :: Int
unit q where
  signature H where y :: Int
unit r where
  include p
  include q
  module A where import H(x,y)

When A imports H, it should see both x and y (i.e. a merged version of the two signatures.) There are two possible ways to implement this:

1. The old strategy: When A imports H, it somehow "sees" both the interface for H from p, and the interface from q, and it merges them together on-the-fly.
2. The new strategy: Before compiling A, we merge the interfaces together, and use that merged interface as what A imports and gets its export from.

Strategy (2) has a few advantages: in separate compilation, it avoids the need to repeatedly merge interfaces together, and it also simplifies GHC in that we don't have to manage on the fly signature merging.

Now the challenge: GHC currently assumes that every build product is associated with a source file: however, merged interface files don't have this property. Both --make and one-shot -c compilation infrastructure is organized around this property.

Here's is the proposal for how to slot this in:

1. Eliminate HscSource distinction between HsBootFile and HsigFile: the file is always called A.hs-boot. Instead, the type checker simply behaves differently depending on whether or not we know what the underlying implementation of A is (passed in using the -sig-of flag. If we know the underlying implementation is containers:Data.Map, we compile the hs-boot file "signature-style", if we don't, we assume it's this-package:A and compile it "boot-style" (Conceivably for cross-unit mutual recursion this will need to be more sophisticated, but this will do for now.) By the way, this means that all signature files now compile to A.hi-boot.
2. We introduce a new HscSource type, HsBootMerge, representing an hi (and stub o) file that will be generated by a signature merge. Intuitively, this operation will merge together A.hi-boot as well as any signatures which were brought into scope by a -package flag. Unlike HsSrcFile and HsBootFile, ModSummarys that are HsBootMerge don't have a source file.
3. When compiling --make, for all "signature-style" hs-boot files in the module graph, we generate an HsBootMerge summary to serve as the NotBoot node of that module name. This means if you import A, you're actually importing the HsBootMerge that produces A.hi.
4. When compiling one-shot, we have a new command for generating the HsBootMerge: ghc --merge-requirements A. This will go and look for an A.hi-boot as well as any external signatures and merge them together. Note that we can't use the existing compilation pipeline -c to generate merged hs-boot files, since these presuppose that there is some input source file, which there is none in this case.
5. When generating a Makefile dependency graph, an entry for an HsBootMerge looks like this:

A.o : A.hi-boot
A.o : /path/to/ghc/foo-0.1/A.hi # if -include-pkg-deps is added

That is to say, an HsBootMerge looks like a normal source file that imports each signature it's merging together, but doesn't have a source file associated with it. One downside with this representation is that it makes Makefile rules a little more complicated: how do you build A.o? Not with ghc -c A.hs, but with ghc --merge-requirements A. I'm not sure what the best way of solving this is.

Trac metadata

Trac field	Value
Version	7.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture