#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