| 1b257afbae854c6817f26b7d61c4fed8ff7aebad |
|
11-Dec-2012 |
Douglas Gregor <dgregor@apple.com> |
Use @import rather than @__experimental_modules_import, since the
latter is rather a mess to type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169919 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|
| 32ad2ee2618745ce3da51c2ae066ed5f21157c07 |
|
01-Mar-2012 |
Ted Kremenek <kremenek@apple.com> |
Change @import to @__experimental_modules_import. We are not ready to commit to a particular syntax for modules,
and don't have time to push it forward in the near future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151841 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|
| c13a34b690d2dc2a03c2fea75a0a1438636c19ce |
|
03-Jan-2012 |
Douglas Gregor <dgregor@apple.com> |
Eliminate the uglified keyword __import_module__ for importing
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.
Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147467 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|
| 65030af6526748ce11534e92f0ccefc44091ba13 |
|
31-Aug-2011 |
Douglas Gregor <dgregor@apple.com> |
Switch __import__ over to __import_module__, so we don't conflict with
existing practice with Python extension modules. Not that Python
extension modules should be using a double-underscored identifier
anyway, but...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138870 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|
| 6aa52ec6b969faabf3764baf79d89810b8249a7e |
|
27-Aug-2011 |
Douglas Gregor <dgregor@apple.com> |
Introduce support for a simple module import declaration, which
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138679 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|
| fac4ece118d43e43e625c6d2b9a98905b1372d51 |
|
19-Aug-2011 |
Douglas Gregor <dgregor@apple.com> |
Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.
This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.
Note that this version moves the file-opening logic into the module
manager, rather than splitting it between the module manager and the
AST reader. More importantly, it properly handles the
weird-but-possibly-useful case of loading an AST file from "-".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138030 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|
| 870d1fee3c5027efe7fd23d6935952bc1f419f99 |
|
18-Aug-2011 |
Chad Rosier <mcrosier@apple.com> |
Temporarily revert r137925 to appease buildbots. Original commit message:
Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.
This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137971 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|
| a4c189f4356f24d984aac781d7762b8c55082b7e |
|
18-Aug-2011 |
Douglas Gregor <dgregor@apple.com> |
Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.
This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137925 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Modules/Inputs/diamond_bottom.h
|