#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
