[LLVMbugs] [Bug 19501] New: lazy loading of module maps causes fragile and weird behavior if a module map names a header not under it

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19501

            Bug ID: 19501
           Summary: lazy loading of module maps causes fragile and weird
                    behavior if a module map names a header not under it
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

We have an impedance mismatch between how header search finds headers named in
module maps and how header search finds a module map once it's found a header
file. Specifically:

If a module map M names a header H, but searching for a module map from H does
not find M, then H /may or may not/ be considered to be part of one of M's
modules, depending on what *other* includes have been processed beforehand.

This situation is terrible. One place where it arises is that a module map for
/usr/include will typically want to name headers provided by the compiler; we
artificially work around that particular case by loading all module maps
directly contained within system header directories when a lib/Headers header
is included, but that's a hack that doesn't generalize.

Another place where it arises is with generated code: a module map for LLVM
would want to name 'llvm/Support/DataTypes.h', but such a module map won't work
reliably unless it lives in the build tree, and that means we can't reliably
build a module containing both files from the source tree and files from the
build tree (and when this fails, it fails mysteriously).


We could easily make this fail less mysteriously: if we load a module map, and
we find that we've already included one of the headers named by that module map
as a non-modular header, then we can issue a warning suggesting that the user
use -fmodule-map-file= to force the module map to be loaded before it's needed.

More aggressively, we could check that each non-excluded header named in an
implicitly-loaded module map would find that module map (had it not already
been loaded).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140421/3ba0f0fa/attachment.html>