diff options
author | Daniel Gröber <dxld@darkboxed.org> | 2019-05-24 15:02:45 +0200 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2019-05-30 16:44:08 -0400 |
commit | 76c86fca43a4e5449f69c5bc1623f4890ae918e2 (patch) | |
tree | ebc3c124da0453101620954daf213e3d5a93e2d2 /config.sub | |
parent | 8e85ebf765e2b6d692e5581f38ff2923e74daa54 (diff) | |
download | haskell-76c86fca43a4e5449f69c5bc1623f4890ae918e2.tar.gz |
Refactor summarise{File,Module} to extract checkSummaryTimestamp
This introduces a slight change of behaviour in the interrest of keeping
the code simple: Previously summariseModule would not call
addHomeModuleToFinder for summaries that are being re-used but now we do.
We're forced to to do this in summariseFile because the file being
summarised might not even be on the regular search path! So if GHC is to
find it at all we have to pre-populate the cache with its location. For
modules however the finder cache is really just a cache so we don't have to
pre-populate it with the module's location.
As straightforward as that seems I did almost manage to introduce a bug (or
so I thought) because the call to addHomeModuleToFinder I copied from
summariseFile used to use `ms_location old_summary` instead of the
`location` argument to checkSummaryTimestamp. If this call were to
overwrite the existing entry in the cache that would have resulted in us
using the old location of any module even if it was, say, moved to a
different directory between calls to 'depanal'.
However it turns out the cache just ignores the location if the module is
already in the cache. Since summariseModule has to search for the module,
which has the side effect of populating the cache, everything would have
been fine either way.
Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.
Diffstat (limited to 'config.sub')
0 files changed, 0 insertions, 0 deletions