Refactor summarise{File,Module} to extract checkSummaryTimestamp
authorDaniel Gröber <dxld@darkboxed.org>
Fri, 24 May 2019 13:02:45 +0000 (15:02 +0200)
committerMarge Bot <ben+marge-bot@smart-cactus.org>
Thu, 30 May 2019 20:44:08 +0000 (16:44 -0400)
commit76c86fca43a4e5449f69c5bc1623f4890ae918e2
treeebc3c124da0453101620954daf213e3d5a93e2d2
parent8e85ebf765e2b6d692e5581f38ff2923e74daa54
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.
compiler/main/GhcMake.hs
testsuite/tests/ghc-api/downsweep/OldModLocation.hs [new file with mode: 0644]
testsuite/tests/ghc-api/downsweep/OldModLocation.stderr [new file with mode: 0644]
testsuite/tests/ghc-api/downsweep/all.T