================
Comment at: lib/Lex/ModuleMap.cpp:346-347
@@ -345,4 +345,1 @@
- // Cannot use a module if it is unavailable.
- if (!H.getModule()->isAvailable())
- continue;
if (!Result || isBetterKnownHeader(H, Result))
----------------
rsmith wrote:
> Should we also teach `isBetterKnownHeader` to consider an available module to
> be better than an unavailable one? (If I have two modules covering a header
> file, and one of them requires "blah" and the other requires "!blah", we
> should presumably pick the available module.)
I'm having a hard time thinking of a legitimate use for that, or in general to
ever have two modules referencing the same file. Do you have something in
particular in mind?
But that does raise the larger question is how to make this insensitive to
whatever order we are iterating here (which I assume is determined in some
relatively fragile way by the order of command line arguments or order in the
module map file). From a user's perspective, it is extremely jarring to have
the compiler's behavior depend in a fragile way on such things (like the unix
linker order-dependence fiasco). I would prefer to just have a hard error if
two modules reference the same header, thus we wouldn't even be iterating here
at all, and users will always be immediately alerted to errors.
http://reviews.llvm.org/D10423
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
