<html>
<head>
<base href="https://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 --- - Prune the include path for modules"
href="https://llvm.org/bugs/show_bug.cgi?id=26928">26928</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Prune the include path for modules
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>MacOS X
</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>aprantl@apple.com
</td>
</tr>
<tr>
<th>CC</th>
<td>dgregor@apple.com, llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Currently the Darwin module self host [1] is broken because libc++ provide its
own overlay versions of libc headers which include the libc headers from the
Darwin
module, which include other libc headers, for which clang then finds the libc++
overlays instead of the libc version.
[1] <a href="http://lab.llvm.org:8080/green/view/All/job/clang-stage2-cmake-modulesRDA/">http://lab.llvm.org:8080/green/view/All/job/clang-stage2-cmake-modulesRDA/</a>
>From the discussion in
<a href="http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151012/141031.html">http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151012/141031.html</a>
<span class="quote">>> What we really need here is a way to get the Darwin blah.h headers to
>> only include each other, and not find the libc++ headers. Do you need
>> something that works with new libc++ and old Clang, or would a Clang
>> feature to prevent the Darwin module from finding the std module's headers
>> work for you?
>></span >
>
<span class="quote">> I've run into this issue in the wild with the modularized PS4 SDK, so I
> think that a clang feature that prevents this is the best fit. I think I
> may have already mentioned this to you at one of the socials but just to
> have it in writing here for everybody else, the root cause of the issue is
> that `-Imylib` will cause mylib/assert.h to be selected for `#include
> <assert.h>`, even when building the system module. Hence some random user
> header will end up as being part of the system module and the seed for
> problems has been planted.</span >
>
<span class="quote">> If the random user header then ends up including code from a module that
> depends on the system module, then clang will go off and build this other
> module, which itself (say) depends on the system module, which triggers the
> recursive dependency error.</span >
>
<span class="quote">> There's nothing special about system headers for this issue, but due to
> their position at the root of the dependency tree they seem to be the ones
> affected in practice. The fundamental problem is that some random header
> outside the module is interposing for the header listed in the module map.
> I think the feature basically needs to be about making the module more
> "hermetically sealed" in this scenario. Off the top of my head, maybe
> something like putting the module map's directory at the front of the
> search path for includes? That seems sort of hacky. Any ideas?</span >
>
I was thinking: if we found the module map for a module in some include
path, then we should build that module with only the directories from the
header search path at or before that directory in the list of include dirs.
That's probably a fairly simple change.</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>