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

27 lines
808 B
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
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... llvm-svn: 138870
2011-09-01 02:19:09 +08:00
#define import __import_module__
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;
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... llvm-svn: 138870
2011-09-01 02:19:09 +08:00
#define IMPORT(X) __import_module__ 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);
}
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 -emit-module option, which emitted a module by parsing a source file (e.g., a header). Immediately steal this useful option name for building modules from a module map file. llvm-svn: 145444
2011-11-30 06:42:06 +08:00
// RUN: %clang_cc1 -emit-module -fmodule-cache-path %t -fmodule-name=lookup_left_cxx -x c++ %S/Inputs/module.map -verify
// RUN: %clang_cc1 -emit-module -fmodule-cache-path %t -fmodule-name=lookup_right_cxx -x c++ %S/Inputs/module.map -verify
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: %clang_cc1 -x c++ -fmodule-cache-path %t %s -verify
// RUN: %clang_cc1 -ast-print -x c++ -fmodule-cache-path %t %s | FileCheck -check-prefix=CHECK-PRINT %s
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)