Commit Graph

104 Commits

Author SHA1 Message Date
Ben Langmuir cb69b57b2a Add dependencies from imported modules with -MD
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
2014-03-07 06:40:32 +00:00
Richard Smith 131daca01d Remove a dead store, add a FIXME for another.
llvm-svn: 203169
2014-03-06 21:59:38 +00:00
Richard Smith 8c71eba19f If a #include finds a file relative to the current file, don't forget to check
whether it's part of a module.

llvm-svn: 203005
2014-03-05 20:51:45 +00:00
Richard Smith 7794486846 Add [extern_c] attribute for modules, allowing a C module to be imported within an extern "C" block in C++ code.
llvm-svn: 202615
2014-03-02 05:58:18 +00:00
Daniel Jasper 92669ee45c Enable layering check in unavailable modules.
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
2013-12-20 12:09:36 +00:00
Daniel Jasper 0761a8a085 Modules: Don't warn upon missing headers while reading the module map.
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
2013-12-17 10:31:37 +00:00
Daniel Jasper 34dc4811a2 Revert "Modules: Make missing headers in a module.map a warning not an error."
This was committed accidentally.

llvm-svn: 197389
2013-12-16 14:57:22 +00:00
Daniel Jasper 5c6ee49fa0 Modules: Make missing headers in a module.map a warning not an error.
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
2013-12-16 14:53:57 +00:00
Daniel Jasper 4eaf0a6ca4 Modules: Let -fmodules-decluse ignore headers that aren't in a module
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
2013-12-11 12:13:00 +00:00
Daniel Jasper 3cd34c7637 Allow string literals as module names.
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
2013-12-06 09:25:54 +00:00
Richard Smith a3feee2ad6 Allow a new syntax in a module requires-declaration:
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
2013-10-28 22:18:19 +00:00
Manuel Klimek 1f76c4e810 Use the same SourceManager for ModuleMaps and compilations.
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
2013-10-24 07:51:24 +00:00
Daniel Jasper 97da9178ce Allow a header to be part of multiple modules.
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
2013-10-22 08:09:47 +00:00
Daniel Jasper 9a59e2c688 Fix uninitialized value bug discovered buy msan buildbot.
llvm-svn: 191292
2013-09-24 12:30:27 +00:00
Daniel Jasper ba7f2f7110 Module use declarations (II)
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
2013-09-24 09:14:14 +00:00
Benjamin Kramer 2d4d8cb329 Simplify code with the in place path::native. No functionality change.
llvm-svn: 190515
2013-09-11 11:23:15 +00:00
Daniel Jasper 97292843d0 Support for modular module-map-files
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
2013-09-11 07:20:44 +00:00
Benjamin Kramer 17381a0627 Use the multiple argument form of path::append.
llvm-svn: 185164
2013-06-28 16:25:46 +00:00
Douglas Gregor 963c553564 [Modules] If a module map resides in a system header directory, treat it as a system module.
This prevents -pedantic from causing warnings in the system headers
used to create modules. Fixes <rdar://problem/14201171>.

llvm-svn: 184560
2013-06-21 16:28:10 +00:00
Lawrence Crowl b53e5483b0 This patch adds new private headers to the module map. Private
headers may be included from within the module, but not from outside
the module.

llvm-svn: 184471
2013-06-20 21:14:14 +00:00
Rafael Espindola 552c169ed3 Include Path.h instead of PathV2.h.
I am about to move PathV2.h to Path.h.

llvm-svn: 183795
2013-06-11 22:15:02 +00:00
Douglas Gregor 64a1fa5cda [Modules] Make r180934 more efficient by only loading top-level module maps in system header directories.
llvm-svn: 181643
2013-05-10 22:52:27 +00:00
Argyrios Kyrtzidis 6f722b4eb9 [modules] When building a module, make sure we don't serialize out HeaderFileInfo for headers not belonging to the module.
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
2013-05-08 23:46:46 +00:00
Douglas Gregor 6b930967e8 When building a module, forward diagnostics to the outer diagnostic consumer.
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
2013-05-03 22:58:43 +00:00
Douglas Gregor 34d52749e4 When looking for the module associated with one of our magical builtin headers, speculatively load module maps.
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
2013-05-02 17:58:30 +00:00
Douglas Gregor fb9126578e <rdar://problem/12368093> Extend module maps with a 'conflict' declaration, and warn when a newly-imported module conflicts with an already-imported module.
llvm-svn: 177577
2013-03-20 21:10:35 +00:00
Douglas Gregor 35b13ece23 <rdar://problem/10796651> Introduce configuration macros into module maps.
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
2013-03-20 00:22:05 +00:00
Argyrios Kyrtzidis b146baabad [Modules] Don't eagerly load and associate all the module header files.
In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers
in order to associate the FileEntries with their modules and support implicit
module import.

Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about
the module that a header belongs to, and associate it with its module only when
there is a request for loading the header info for a particular file.

Part of rdar://13391765

llvm-svn: 176976
2013-03-13 21:13:51 +00:00
Argyrios Kyrtzidis 3c5305c15e [Modules] Resolve top-headers of modules lazily.
This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.

Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.

llvm-svn: 176975
2013-03-13 21:13:43 +00:00
Argyrios Kyrtzidis e441264019 [modules] Const'ify some functions of ModuleMap.
llvm-svn: 175552
2013-02-19 19:58:45 +00:00
Jordan Rose a7d03840e6 Excise <cctype> from Clang (except clang-tblgen) in favor of CharInfo.h.
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.

llvm-svn: 174768
2013-02-08 22:30:41 +00:00
Dmitri Gribenko eadae014ed <limits.h> includes <linux/limits.h> on Linux, no need to special-case it
llvm-svn: 173578
2013-01-26 16:29:36 +00:00
Douglas Gregor e00c8b205e Since we're stuck with realpath for the header <-> module mapping,
factor the realpath calls into FileManager::getCanonicalName() so we
can cache the results of this epically slow operation. 5% speedup on
my modules test, and realpath drops out of the profile.

llvm-svn: 173542
2013-01-26 00:55:12 +00:00
Douglas Gregor 01c7cfa2c0 Fix compilation on Linux, which defines PATH_MAX in a weird place,
from Saleem Abdulrasool!

llvm-svn: 173208
2013-01-22 23:49:45 +00:00
Douglas Gregor 11dfe6fe3d Infer "link" lines for top-level frameworks. Essentially, a framework
will have a shared library with the same name as its framework (and no
suffix!) within its .framework directory. Detect this both when
inferring the whole top-level framework and when parsing a module map.

llvm-svn: 172439
2013-01-14 17:57:51 +00:00
Douglas Gregor 6ddfca91e0 Implement parsing, AST, (de-)serialization, and placeholder global
metadata for linking against the libraries/frameworks for imported
modules.

The module map language is extended with a new "link" directive that
specifies what library or framework to link against when a module is
imported, e.g.,

  link "clangAST"

or

  link framework "MyFramework"

Importing the corresponding module (or any of its submodules) will
eventually link against the named library/framework.

For now, I've added some placeholder global metadata that encodes the
imported libraries/frameworks, so that we can test that this
information gets through to the IR. The format of the data is still
under discussion.

llvm-svn: 172437
2013-01-14 17:21:00 +00:00
Dmitri Gribenko f857950d39 Remove useless 'llvm::' qualifier from names like StringRef and others that are
brought into 'clang' namespace by clang/Basic/LLVM.h

llvm-svn: 172323
2013-01-12 19:30:44 +00:00
Douglas Gregor 4ddf2221b4 Rework the realpath nonsense for framework lookups to deal more
uniformly with symlinks between top-level and embedded frameworks.

llvm-svn: 172030
2013-01-10 01:43:00 +00:00
Douglas Gregor 7426050269 realpath'ify the mapping from header includes to module imports.
llvm-svn: 171516
2013-01-04 19:44:26 +00:00
Bill Wendling 4442605f18 Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here.
llvm-svn: 170721
2012-12-20 19:22:21 +00:00
Bill Wendling 7967fc14b9 Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future.
llvm-svn: 170500
2012-12-19 07:18:12 +00:00
Chandler Carruth 3a02247dc9 Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237
2012-12-04 09:13:33 +00:00
Douglas Gregor 4b27a64b92 If an excluded header does not exist, just ignore it
llvm-svn: 168077
2012-11-15 19:47:16 +00:00
Douglas Gregor 162405da9b Remove C++11-isms I just introduced in r167482
llvm-svn: 167483
2012-11-06 19:41:11 +00:00
Douglas Gregor 9194a91dc9 Introduce inferred framework modules into the module map file,
allowing a module map to be placed one level above the '.framework'
directories to specify that all .frameworks within that directory can
be inferred as framework modules. One can also specifically exclude
frameworks known not to work.

This makes explicit (and more restricted) behavior modules have had
"forever", where *any* .framework was assumed to be able to be built
as a module. That's not necessarily true, so we white-list directories
(with exclusions) when those directories have been audited.

llvm-svn: 167482
2012-11-06 19:39:40 +00:00
Douglas Gregor 811db4eac4 Make DiagnosticOptions intrusively reference-counted, and make sure
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.

llvm-svn: 166508
2012-10-23 22:26:28 +00:00
Douglas Gregor bc10b9fbc5 Teach TargetInfo to hold on to the TargetOptions with which it was
created.

llvm-svn: 165943
2012-10-15 16:45:32 +00:00
Douglas Gregor 5952766628 Introduce the notion of excluded headers into the module map
description. Previously, one could emulate this behavior by placing
the header in an always-unavailable submodule, but Argyrios guilted me
into expressing this idea properly.

llvm-svn: 165921
2012-10-15 06:28:11 +00:00
Douglas Gregor 056396ae8c Sanitize the names of modules determined based on the names of headers
or directories, to make sure that they are identifiers that are not
keywords in any dialect. Fixes <rdar://problem/12489495>.

llvm-svn: 165821
2012-10-12 21:15:50 +00:00
Argyrios Kyrtzidis c597c8c48b [Modules] Introduce Module::TopHeaders which is a set of top-level headers
that are associated with a (sub)module.

llvm-svn: 165279
2012-10-05 00:22:33 +00:00