[GHC] #12994: Module and export level signature thinning in Backpack

[GHC]

#12994: Module and export level signature thinning in Backpack
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.1
  checker)                           |
      Resolution:                    |             Keywords:  backpack
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Edward Z. Yang <ezyang@…>):

 In [changeset:"5f9c6d2a91ac710e7b75cfe50a7a8e84cc9ae796/ghc"
 5f9c6d2a/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="5f9c6d2a91ac710e7b75cfe50a7a8e84cc9ae796"
 Support for using only partial pieces of included signatures.

 Summary:
 Generally speaking, it's not possible to "hide" a requirement from a
 package you include, because if there is some module relying on that
 requirement, well, you can't just wish it out of existence.

 However, some packages don't have any modules.  For these, we can
 validly thin out requirements; indeed, this is very convenient if
 someone has published a large signature package but you only want
 some of the definitions.

 This patchset tweaks the interpretation of export lists in
 signatures: in particular, they no longer need to refer to
 entities that are defined locally; they range over both the current
 signature as well as any signatures that were inherited from
 signature packages (defined by having zero exposed modules.)

 In the process of doing this, I cleaned up a number of other
 things:

 * rnModIface and rnModExports now report errors that occurred
   during renaming and can propagate these to the TcM monad.
   This is important because in the current semantics, you can
   thin out a type which is referenced by a value you keep;
   in this situation, we need to error (to ensure that all
   types in signatures are rooted, so that we can determine
   their identities).

 * I ended up introducing a new construct 'dependency signature;
   to bkp files, to make it easier to tell if we were depending
   on a signature package.  It's not difficult for Cabal to
   figure this out (I already have a patch for it.)

 Signed-off-by: Edward Z. Yang <ezyang at cs.stanford.edu>

 Test Plan: validate

 Reviewers: simonpj, austin, bgamari

 Subscribers: thomie, mpickering

 Differential Revision: https://phabricator.haskell.org/D2904

 GHC Trac Issues: #12994
 }}}

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