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: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
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.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
