[cfe-dev] Module maps, __FILE__ and lazy stat'ing of headers

[Manuel Klimek]

Hi Richard,

while working with module maps for layering checks a problem with __FILE__
we noticed triggered a couple of questions.

The problem is that __FILE__ uses the path of the first 'stat' call (as
that is how FileManager::getFile() works).
Currently we parse all module maps at the beginning of the TU, and stat all
headers while doing so; there is a FIXME in
ModuleMapParser::parseHeaderDecl that reminds us this might not be a good
idea, and that we'd want to somehow lazily stat the headers anyway.
Regardless, currently the first 'stat' to a header when using
strict-decluse is usually the way the header is referenced by its module's
module map; this is often very different from what the user expects, and
certainly different from how this used to work (using -I relative path via
which a header is usually found).

There are multiple possible solutions, but the first one we thought about
was to fix the header stat'ing FIXME, which would naturally solve this
problem by pushing the first stat of the header after the stat from the
#include.
The problem with that approach is:
1. We currently have some places that look up a module for a header; we at
least need to resolve the headers of all direct dependencies of the module
map; I'm unsure what the effect of only finding the headers of the current
module and its direct dependencies would be.
2. We need to find a place in the code at which to resolve / stat all
headers in the current module map (and its direct dependencies); this needs
to be after preprocessing (thus we'd need to delay diags related to modules
while parsing #include directives). It seems to me like this would allow us
to also resolve headers only for the current module and its direct deps, at
least if my theory is correct that preprocessing would happen once per file
per module being built (even on recursive module build invocations)

After looking into it, it seems like this is significant effort, so we're
somewhat hoping to find an intermediate solution that is less effort and
allows us to fix the above problems together with the work on full modules.

Thoughts?
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140728/8b1c408b/attachment.html>