Refactor summarise{File,Module} to extract checkSummaryTimestamp
authorDaniel Gröber <dxld@darkboxed.org>
Fri, 24 May 2019 13:02:45 +0000 (15:02 +0200)
committerBen Gamari <ben@well-typed.com>
Tue, 4 Jun 2019 03:42:11 +0000 (23:42 -0400)
commit01bb7ec351563afbba5bdd8d3153b454e19eb1c5
tree2fb3e9b90d95930503e615645eb4a2330f8e2bf6
parent35f9fdae4ee335cb37e7e8bb0f9938d0fe8af514
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