#4900: DEPENDS pragma -------------------------------+-------------------------------------------- Reporter: cdsmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: TH_Depends | Blockedby: Blocking: | Related: -------------------------------+--------------------------------------------
Comment(by parcs): Replying to [comment:53 simonmar]: > I looked at the new patch, and maybe I'm being stupid here, but it looks like my previous concerns still apply. Looking at the HPT during the summarise stage rings alarm bells - the `hsc_env` should only be used for its `DynFlags` and the finder cache. So I'm still not sure how to reason that this patch works correctly. Regarding your previous concerns, the important part of this new patch is that `ms_uf_date` is not read at all during the summarize stage; it is only used to propagate the latest usage file date computed during the summarize stage to the stability check. Instead of comparing the previous `ms_uf_date` to the latest `ms_uf_date`, as the last patch did, the `usg_mtime`s are compared and calculated piecewise from the module's `HMI`. This is better because these mtimes get calculated during the `upsweep`, meaning that they will be as accurate as they can be for the next `load` cycle. (Compare the current `isOkUsageFileDate` with the previous patch's `getUsageFileDate`). I _believe_ that reading the `HPT` in the way that is done in the patch is safe -- it is only read if an old summary is available. Is it guaranteed that if an old summary is available, then a corresponding `HMI` exists within the `HPT`? It seems so, but I am not sure. Also, I should mention that it is necessary to compute and check the usage file dates before or during the summarise stage, because that's when a file is ran through the preprocessor, and a usage file may be a CPP include. Without the `HPT`, the only real information you have at that point is an old `ModSummary`. Therefore, if the `HPT` should not be read during the summarise stage, then it seems that the only alternative would be to stuff the `UsageFile` data from the `HMI` to a field of the corresponding `ModSummary`. An `HMI` is created during the `upsweep` stage, so the `hsc_mod_graph` would have to be updated after the `upsweep` occurs, which is currently not done and doing so would probably introduce its own subtleties. (Currently, the mod graph is only updated right after the summarise stage). Does this seem more reasonable to you? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4900#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs