We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
llvm-svn: 239789
This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.
So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.
llvm-svn: 236350
headers even if they arrived when merging non-system modules.
The idea of this code is that we don't want to warn the user about
macros defined multiple times by their system headers with slightly
different definitions. We should have this behavior if either the
macro comes from a system module, or the definition within the module
comes from a system header. Previously, we would warn on ambiguous
macros being merged when they came from a users modules even though they
only showed up via system headers.
By surviving this we can handle common system header macro differences
like differing 'const' qualification of pointers due to some headers
predating 'const' being valid in C code, even when those systems headers
are pre-built into a system module.
Differential Revision: http://reviews.llvm.org/D8310
llvm-svn: 232149
Richard Smith