<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - lazy loading of module maps causes fragile and weird behavior if a module map names a header not under it"
href="http://llvm.org/bugs/show_bug.cgi?id=19501">19501</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>lazy loading of module maps causes fragile and weird behavior if a module map names a header not under it
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Modules
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>richard-llvm@metafoo.co.uk
</td>
</tr>
<tr>
<th>CC</th>
<td>dgregor@apple.com, llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>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).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>