[GHC] #4900: DEPENDS pragma

[GHC]

#4900: DEPENDS pragma
-------------------------------------+------------------------------------
        Reporter:  cdsmith           |            Owner:
            Type:  feature request   |           Status:  patch
        Priority:  normal            |        Milestone:  7.8.1
       Component:  Compiler          |          Version:
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:  TH_Depends        |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by parcs):

 Replying to [comment:63 simonmar]:
 > At first glance it's not obviously right, since we don't normally modify
 `ModSummary` during the upsweep - the `ModSummary` is something that is
 supposed to be collected by the downsweep.

 A module's list of usage files can only be determined _after_ compiling
 the module because the list includes files added by TH's
 `qAddDependencies`. So one way or another, usage-file information has to
 be propagated from a previous upsweep to a future downsweep (and to the
 stability check that follows).

 I proposed two independent solutions:

 1. During the downsweep, look inside the HPT to extract the usage-file
 information from an existing HMI and stuff it into the !ModSummary.
 2. During the upsweep, extract the usage-file information from the new HMI
 and update the module graph with this information. A future downsweep will
 use this updated module graph.

 But these solutions don't exactly satisfy the existing invariants of the
 downsweep and upsweep. For (1), we shouldn't read the HPT during the
 downsweep. For (2), we shouldn't update a !ModSummary during the upsweep.
 But I can't think of another solution. I personally like (1), especially
 since there are two independent upsweeps now. The patch that Adam attached
 is an updated version of (2).

 I think it would help review if a future patch was split into several
 logical patches. It's not a lot of code but it's somewhat tricky code.

 This is just my understanding of the state of this ticket.

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