Commit Graph

45 Commits

Author SHA1 Message Date
Richard Smith 306d892076 [modules] Add support for 'textual header' directives.
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
2014-10-22 23:50:56 +00:00
Ben Langmuir 9d6448b137 Refactor the module map file used for uniquing a module name out of
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
2014-08-09 00:57:23 +00:00
Craig Topper f1186c5a8f [C++11] Use 'nullptr'.
llvm-svn: 208280
2014-05-08 06:41:40 +00:00
Ben Langmuir ffbafa2af0 Do not print inferred submodules explicitly in __inferred_module.map
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
2014-04-23 21:10:46 +00:00
Richard Smith 86dbed7577 Initialize clang::Module::IsMissingRequirement. Fix msan issue and hopefully some builder failures.
llvm-svn: 206736
2014-04-21 07:28:16 +00:00
Ben Langmuir 993055f860 Fix a hole with nested unavailable submodules from r206664
If a module doesn't meet a requirement, neither do its submodules. If we
don't propogate that, we might think it's an error to be missing a
header in one of those submodules.

llvm-svn: 206673
2014-04-18 23:51:00 +00:00
Ben Langmuir ec8c975214 Don't build modules with (submodules with) missing headers
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
2014-04-18 22:07:31 +00:00
Dmitri Gribenko 62bcd925c0 Add more constness to module-related APIs
llvm-svn: 206595
2014-04-18 14:36:51 +00:00
Ben Langmuir beee15e721 Allow multiple modules with the same name to coexist in the module cache
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
2014-04-14 18:00:01 +00:00
Richard Smith 9bca298f6d Module [extern_c] attribute: inherit to submodules, don't write 'extern "C"'
blocks when building in C mode, and serialize and deserialize the attribute.

llvm-svn: 203317
2014-03-08 00:03:56 +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 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
Dmitri Gribenko e9bcf5b7b1 Include non-explicit submodules in exported module list
This change fixes Richard's testcase for r193815.  Now we include non-explicit
submodules into the list of exports.

The test failed previously because:
- recursive_visibility_a1.inner is not imported (only recursive_visibility_a1 is),
- thus the 'inner' submodule is not showing up in any of the import lists,
- and because of this getExportedModules() is not returning the
  correct module set -- it only considers modules that are imported.

The fix is to make Module::getExportedModules() include non-explicit submodules
into the list of exports.

llvm-svn: 194018
2013-11-04 21:51:33 +00:00
Richard Smith dde17e74fa Simplify computation of visible module set.
llvm-svn: 193850
2013-11-01 02:19:14 +00:00
Dmitri Gribenko dc360d5739 Clang modules: collect exports recursively
This change makes Module::buildVisibleModulesCache() collect exported modules
recursively.

While computing a set of exports, getExportedModules() iterates over the set of
imported modules and filters it.  But it does not consider the set of exports
of those modules -- it is the responsibility of the caller to do this.

Here is a certain instance of this issue.  Module::isModuleVisible says that
CoreFoundation.CFArray submodule is not visible from Cocoa.  Why?

- Cocoa imports Foundation.
- Foundation has an export restriction: "export *".
- Foundation imports CoreFoundation.  (Just the top-level module.)
- CoreFoundation exports CoreFoundation.CFArray.

To decide which modules are visible from Cocoa, we collect all exported modules
from immediate imports in Cocoa:

> visibleModulesFro(Cocoa) = exported(Foundation) + exported(CoreData) + exported(AppKit)

To find out which modules are exported, we filter imports according to
restrictions:

> exported(Foundation) = filterByModuleMapRestrictions(imports(Foundation))

Because Foundation imports CoreFoundation (not CoreFoundation.CFArray), the
CFArray submodule is considered not exported from Foundation, and is not
visible from Cocoa (according to Module::isModuleVisible).

llvm-svn: 193815
2013-10-31 22:24:10 +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
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
Richard Smith 0e5d7b8c6b When we perform dependent name lookup during template instantiation, it's not
sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.

The fix here has two parts:

1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.

2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.

There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.

llvm-svn: 187167
2013-07-25 23:08:39 +00:00
Craig Topper 61ac906bdd Use SmallVectorImpl::reverse_iterator instead of SmallVector to avoid specifying the vector size.
llvm-svn: 185784
2013-07-08 03:55:09 +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
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 8d93242709 Make sure that Module::ConfigMacrosExhaustive gets initialized and deserialized correctly.
This fixes regressions introduced in r177466 that caused several
module tests to fail sporadically.

llvm-svn: 177481
2013-03-20 03:59:18 +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 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 8739f7b7f6 [modules] Refactor code from ASTReader::makeModuleVisible() into a new function,
Module::getExportedModules() so it can be reused.

llvm-svn: 175548
2013-02-19 19:34:40 +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
Richard Smith 2bf7fdb723 s/CPlusPlus0x/CPlusPlus11/g
llvm-svn: 171367
2013-01-02 11:42:31 +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 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
Argyrios Kyrtzidis 43af5132c5 In the Module class, add a reference to the corresponding AST file.
llvm-svn: 164873
2012-09-29 01:06:04 +00:00
Douglas Gregor 3ec6663be0 Back out my heinous hack that tricked the module generation mechanism
into using non-absolute system includes (<foo>)...

... and introduce another hack that is simultaneously more heineous
and more effective. We whitelist Clang-supplied headers that augment
or override system headers (such as float.h, stdarg.h, and
tgmath.h). For these headers, Clang does not provide a module
mapping. Instead, a system-supplied module map can refer to these
headers in a system module, and Clang will look both in its own
include directory and wherever the system-supplied module map
suggests, then adds either or both headers. The end result is that
Clang-supplied headers get merged into the system-supplied module for
the C standard library.

As a drive-by, fix up a few dependencies in the _Builtin_instrinsics
module.

llvm-svn: 149611
2012-02-02 18:42:48 +00:00
Douglas Gregor 0070c0bfbe Introduce TargetInfo::hasFeature() to query various feature names in
each of the targets. Use this for module requirements, so that we can
pin the availability of certain modules to certain target features,
e.g., provide a module for xmmintrin.h only when SSE support is
available.

Use these feature names to provide a nearly-complete module map for
Clang's built-in headers. Only mm_alloc.h and unwind.h are missing,
and those two are fairly specialized at the moment. Finishes
<rdar://problem/10710060>.

llvm-svn: 149227
2012-01-30 06:38:25 +00:00
Douglas Gregor 8992928274 Thread a TargetInfo through to the module map; we'll need it for
target-specific module requirements.

llvm-svn: 149224
2012-01-30 06:01:29 +00:00
Douglas Gregor a686e1b05d Introduce module attributes into the module map grammar, along with a
single attribute ("system") that allows us to mark a module as being a
"system" module. Each of the headers that makes up a system module is
considered to be a system header, so that we (for example) suppress
warnings there.

If a module is being inferred for a framework, and that framework
directory is within a system frameworks directory, infer it as a
system framework.

llvm-svn: 149143
2012-01-27 19:52:33 +00:00
David Blaikie 8a40f700e6 Remove unreachable code in Clang. (replace with llvm_unreachable where appropriate or when GCC requires it)
llvm-svn: 148292
2012-01-17 06:56:22 +00:00
Douglas Gregor eb90e83085 Store the submodules of a module in source order, as they are stored
in the module map. This provides a bit more predictability for the
user, as well as eliminating the need to sort the submodules when
serializing them.

llvm-svn: 147564
2012-01-04 23:32:19 +00:00
Douglas Gregor 1fb5c3a63a Implement support for module requirements, which indicate the language
features needed for a particular module to be available. This allows
mixed-language modules, where certain headers only work under some
language variants (e.g., in C++, std.tuple might only be available in
C++11 mode).

llvm-svn: 147387
2011-12-31 04:05:44 +00:00
Douglas Gregor 322f633c1c Tweak the syntax of umbrella headers, so that "umbrella" is treated as
a modifier for a header declarartion, e.g.,

  umbrella header "headername"

Collapse the umbrella-handling code in the parser into the
header-handling code, so we don't duplicate the header-search logic.

llvm-svn: 146159
2011-12-08 18:00:48 +00:00
Douglas Gregor 73141fa98d Within the module representation, generalize the notion of an umbrella
header to also support umbrella directories. The umbrella directory
for an umbrella header is the directory in which the umbrella header
resides.

No functionality change yet, but it's coming.

llvm-svn: 146158
2011-12-08 17:39:04 +00:00
Douglas Gregor 734410916a Parse inferred submodules in module maps, track their contents in
Module, and (de-)serialize this information. Semantics of inferred
submodules to follow.

llvm-svn: 145864
2011-12-05 22:27:44 +00:00
Douglas Gregor 8c7c83522b Fix printing of wildcard exports.
llvm-svn: 145812
2011-12-05 17:34:59 +00:00
Douglas Gregor f5eedd05db Implement support for wildcard exports in modules, allowing a module
to re-export anything that it imports. This opt-in feature makes a
module behave more like a header, because it can be used to re-export
the transitive closure of a (sub)module's dependencies.

llvm-svn: 145811
2011-12-05 17:28:06 +00:00
Douglas Gregor 24bb923aa8 Implement (de-)serialization of the set of exported modules in a
module map. 

llvm-svn: 145695
2011-12-02 18:58:38 +00:00
Douglas Gregor de3ef502a9 Promote ModuleMap::Module to a namespace-scope class in the Basic
library, since modules cut across all of the libraries. Rename
serialization::Module to serialization::ModuleFile to side-step the
annoying naming conflict. Prune a bunch of ModuleMap.h includes that
are no longer needed (most files only needed the Module type).

llvm-svn: 145538
2011-11-30 23:21:26 +00:00