maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Modules/lookup.cpp

35 lines
1.0 KiB
C++
Raw Normal View History

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. llvm-svn: 138679
2011-08-27 07:56:07 +08:00
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. llvm-svn: 151841
2012-03-02 06:07:04 +08:00
#define import @__experimental_modules_import
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. llvm-svn: 138679
2011-08-27 07:56:07 +08:00
import lookup_left_cxx;
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. llvm-svn: 147467
2012-01-04 03:32:59 +08:00
#undef import
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. llvm-svn: 151841
2012-03-02 06:07:04 +08:00
#define IMPORT(X) @__experimental_modules_import X
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. llvm-svn: 138679
2011-08-27 07:56:07 +08:00
IMPORT(lookup_right_cxx);
In the AST reader, switch name lookup within a DeclContect over to the module DAG-based lookup scheme. This required some reshuffling, so that each module stores its own mapping from DeclContexts to their lexical and visible sets for those DeclContexts (rather than one big "chain"). Overall, this allows simple qualified name lookup into the translation unit to gather results from multiple modules, with the lookup results in module B shadowing the lookup results in module A when B imports A. Walking all of the lexical declarations in a module DAG is still a mess; we'll end up walking the loaded module list backwards, which works fine for chained PCH but doesn't make sense in a DAG. I'll tackle this issue as a separate commit. llvm-svn: 138463
2011-08-25 03:03:07 +08:00
void test(int i, float f) {
// unqualified lookup
f0(&i);
f0(&f);
// qualified lookup into the translation unit
::f0(&i);
::f0(&f);
}
Don't treat 'import' as a contextual keyword when we're in a caching lexer, or when modules are disabled. llvm-svn: 147524
2012-01-04 14:20:15 +08:00
int import;
void f() {
int import;
}
Switch some more of the modules tests over to "-emit-module-from-map", and remove stray fprintf. llvm-svn: 144742
2011-11-16 08:21:54 +08:00
// RUN: rm -rf %t
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. llvm-svn: 147467
2012-01-04 03:32:59 +08:00
// RUN: %clang_cc1 -fmodules -x objective-c++ -emit-module -fmodule-cache-path %t -fmodule-name=lookup_left_cxx %S/Inputs/module.map -verify
// RUN: %clang_cc1 -fmodules -x objective-c++ -emit-module -fmodule-cache-path %t -fmodule-name=lookup_right_cxx %S/Inputs/module.map -verify
// RUN: %clang_cc1 -fmodules -x objective-c++ -fmodule-cache-path %t %s -verify
// RUN: %clang_cc1 -fmodules -ast-print -x objective-c++ -fmodule-cache-path %t %s | FileCheck -check-prefix=CHECK-PRINT %s
// FIXME: When we have a syntax for modules in C++, use that.
Introduce a depth-first search of modules into the module manager, which supports both pre-order and post-order traversal via a visitor mechanism. Use this depth-first search with a post-order traversal to give predictable ordering semantics when walking all of the lexical declarations in the translation unit. Eventually, module imports will occur in the source code rather than at the beginning, and we'll have to revisit this walk. llvm-svn: 138490
2011-08-25 05:27:34 +08:00
// CHECK-PRINT: int *f0(int *);
// CHECK-PRINT: float *f0(float *);
// CHECK-PRINT: void test(int i, float f)