This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
We already verified the primary module map file (either the one that
defines the top-level module, or the one that allows inferring it if it
is an inferred framework module). Now we also verify any other module
map files that define submodules, such as when there is a
module.private.modulemap file.
llvm-svn: 215455
class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
the remaining cases. This lets us do less bookkeeping to keep the
ModuleMap fields up to date.
llvm-svn: 215268
Just because we can open a directory named "COcoa.framework" doesn't
mean we should provide a "COcoa" module on a case-insensitive filesystem.
llvm-svn: 212975
But keep -Wnon-modular-include-in-[framework-]module
This warning is too noisy and doesn't really indicate a problem for most
people. Even though it would only really affect people using
-Weverything, that seems bad so remove it.
llvm-svn: 208345
Warn on non-modular includes in various contexts.
-Wnon-modular-include
-Wnon-modular-include-in-module
-Wnon-modular-include-in-framework-module
Where each group is a subgroup of those above it.
llvm-svn: 208004
Otherwise including a header in your source file that is not included by
framework's umbrella header will silently add an empty submodule with that
name.
is automatically translated to
@import Foo.NotInModule;
which then would have succeeded because the inferred module map
contained an empty submodule called NotInModule.
llvm-svn: 207024
Unless they are in submodules that aren't available anyway, due to
requirements not being met. Also, mark children as unavailable when the
parent is.
llvm-svn: 206664
To differentiate between two modules with the same name, we will
consider the path the module map file that they are defined by* part of
the ‘key’ for looking up the precompiled module (pcm file).
Specifically, this patch renames the precompiled module (pcm) files from
cache-path/<module hash>/Foo.pcm
to
cache-path/<module hash>/Foo-<hash of module map path>.pcm
In addition, I’ve taught the ASTReader to re-resolve the names of
imported modules during module loading so that if the header search
context changes between when a module was originally built and when it
is loaded we can rebuild it if necessary. For example, if module A
imports module B
first time:
clang -I /path/to/A -I /path/to/B ...
second time:
clang -I /path/to/A -I /different/path/to/B ...
will now rebuild A as expected.
* in the case of inferred modules, we use the module map file that
allowed the inference, not the __inferred_module.map file, since the
inferred file path is the same for every inferred module.
llvm-svn: 206201
This name, while more verbose, plays more nicely with tools that use
file extensions to determine file types. The existing spelling
'module.map' will continue to work, but the new spelling will take
precedence.
In frameworks, this new filename will only go in a new 'Modules'
sub-directory.
Similarly, add a module.private.modulemap corresponding to
module_private.map.
llvm-svn: 204261
that implicitly converts to 'bool' (such as pointers, and the first operand of
?:). Clean up issues found by this. Patch by Stephan Tolksdorf!
llvm-svn: 203735
Add module dependencies to the dependency files created by -MD/-MMD/etc.
by attaching an ASTReaderListener that will call into the dependency
file generator when a module input file is seen in the serialized AST.
llvm-svn: 203208
If a header file belonging to a certain module is not found on the
filesystem, that header gets marked as unavailable. Now, the layering
warning (-fmodules-decluse) should still warn about headers of this
module being wrongfully included. Currently, headers belonging to those
modules are just treated as not belonging to modules at all which means
they can be included freely from everywhere.
To implement this (somewhat) cleanly, I have moved most of the layering
checks into the ModuleMap. This will also help with showing FixIts
later.
llvm-svn: 197805
Instead, mark the module as unavailable so that clang errors as soon as
someone tries to build this module.
This works towards the long-term goal of not stat'ing the header files at all
while reading the module map and instead read them only when the module is
being built (there is a corresponding FIXME in parseHeaderDecl()). However, it
seems non-trivial to get there and this unblock us and moves us into the right
direction.
Also changed the implementation to reuse the same DiagnosticsEngine.
llvm-svn: 197485
Instead, mark the module as unavailable so that clang errors as soon as
someone tries to build this module.
A better long-term strategy might be to not stat the header files at all
while reading the module map and instead read them only when the module
is being built (there is a corresponding FIXME in parseHeaderDecl()).
However, it seems non-trivial to get there and this would be a temporary
solution to unblock us.
Also changed the implementation to reuse the same DiagnosticsEngine as
otherwise warnings can't be enabled or disabled with command-line flags.
llvm-svn: 197388
Includes might always pull in arbitrary header or data files outside of
modules. Among others, this includes builtin includes, which do not have
a module (story) yet.
Also cleanup implementation of ModuleMap::findModuleForHeader() to be
non-recursive.
llvm-svn: 197034
In order to make the migration to modules easier, it seems to be helpful
to allow a 1:1 mapping between target names of a current build system
and the corresponding C++ modules. As such targets commonly contain
characters like "-". ":" and "/", allowing arbitrary quote-escaped
strings seems to be a straightforward option.
After several offline discussions, the precise mechanisms for C++
module names especially regarding submodules and import statements has
yet to be determined. Thus, this patch only enables string literals as
names inside the module map files which can be used by automatic module
import (through #include).
Also improve the error message on missing use-declarations.
llvm-svn: 196573
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
llvm-svn: 193549
This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).
Two problems needed to be fixed which this patch exposed:
1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.
2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.
llvm-svn: 193314
This patch changes two things:
a) Allow a header to be part of multiple modules. The reasoning is that
in existing codebases that have a module-like build system, the same
headers might be used in several build targets. Simple reasons might be
that they defined different classes that are declared in the same
header. Supporting a header as a part of multiple modules will make the
transistion easier for those cases. A later step in clang can then
determine whether the two modules are actually compatible and can be
merged and error out appropriately. The later check is similar to what
needs to be done for template specializations anyway.
b) Allow modules to be stored in a directory tree separate from the
headers they describe.
Review: http://llvm-reviews.chandlerc.com/D1951
llvm-svn: 193151
Review: http://llvm-reviews.chandlerc.com/D1546.
I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.
From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:
use module-id
A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.
When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option
-fmodule-name=<module-id>.
The compiler at present only applies restrictions to the module directly
being built.
llvm-svn: 191283
This patch is the first step to make module-map-files modular (instead
of requiring a single "module.map"-file per include directory). This
step adds a new "extern module" declaration that enables
module-map-files to reference one another along with a very basic
implementation.
The next steps are:
* Combine this with the use-declaration (from
http://llvm-reviews.chandlerc.com/D1546) in order to only load module
map files required for a specific compilation.
* Add an additional flag to start with a specific module-map-file (instead
of requiring there to be at least one "module.map").
Review: http://llvm-reviews.chandlerc.com/D1637
llvm-svn: 190497
After r180934 we may initiate module map parsing for modules not related to the module what we are building,
make sure we ignore the header file info of headers from such modules.
First part of rdar://13840148
llvm-svn: 181489
Previously, we would clone the current diagnostic consumer to produce
a new diagnostic consumer to use when building a module. The problem
here is that we end up losing diagnostics for important diagnostic
consumers, such as serialized diagnostics (where we'd end up with two
diagnostic consumers writing the same output file). With forwarding,
the diagnostics from all of the different modules being built get
forwarded to the one serialized-diagnostic consumer and are emitted in
a sane way.
Fixes <rdar://problem/13663996>.
llvm-svn: 181067
The "magical" builtin headers are the headers we provide as part of
the C standard library, which typically comes from /usr/include. We
essentially merge our headers into that location (due to cyclic
dependencies). This change makes sure that, when header search finds
one of our builtin headers, we figure out which module it actually
lives in. This case is fairly rare; one ends up having to include one
of the few built-in C headers we provide before including anything
from /usr/include to trigger it. Fixes <rdar://problem/13787184>.
llvm-svn: 180934
Configuration macros are macros that are intended to alter how a
module works, such that we need to build different module variants
for different values of these macros. A module can declare its
configuration macros, in which case we will complain if the definition
of a configation macro on the command line (or lack thereof) differs
from the current preprocessor state at the point where the module is
imported. This should eliminate some surprises when enabling modules,
because "#define CONFIG_MACRO ..." followed by "#include
<module/header.h>" would silently ignore the CONFIG_MACRO setting. At
least it will no longer be silent about it.
Configuration macros are eventually intended to help reduce the number
of module variants that need to be built. When the list of
configuration macros for a module is exhaustive, we only need to
consider the settings for those macros when building/finding the
module, which can help isolate modules for various project-specific -D
flags that should never affect how modules are build (but currently do).
llvm-svn: 177466
Richard Smith