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/diamond.c

28 lines
1003 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
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 "-". llvm-svn: 138030
2011-08-19 10:29:29 +08:00
// in diamond-bottom.h: expected-note{{passing argument to parameter 'x' here}}
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
__import_module__ diamond_bottom;
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
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 "-". llvm-svn: 138030
2011-08-19 10:29:29 +08:00
void test_diamond(int i, float f, double d, char c) {
top(&i);
left(&f);
right(&d);
bottom(&c);
bottom(&d); // expected-warning{{incompatible pointer types passing 'double *' to parameter of type 'char *'}}
Introduce a module visitation function that starts at the top-level modules (those that no other module depends on) and performs a search over all of the modules, visiting a new module only when all of the modules that depend on it have already been visited. The visitor can abort the search for all modules that a module depends on, which allows us to minimize the number of lookups necessary when performing a search. Switch identifier lookup from a linear walk over the set of modules to this module visitation operation. The behavior is the same for simple PCH and chained PCH, but provides the proper search order for modules. Verified with printf debugging, since we don't have enough in place to actually test this. llvm-svn: 138187
2011-08-20 12:39:52 +08:00
// Names in multiple places in the diamond.
top_left(&c);
Make the loading of multiple records for the same identifier (from different modules) more robust. It already handled (simple) merges of the set of declarations attached to that identifier, so add a test case that shows us getting two different declarations for the same identifier (one struct, one function) from different modules, and are able to use both of them. llvm-svn: 138189
2011-08-20 13:09:43 +08:00
left_and_right(&i);
struct left_and_right lr;
lr.left = 17;
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 "-". llvm-svn: 138030
2011-08-19 10:29:29 +08:00
}
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
// RUN: %clang_cc1 -emit-module -o %T/diamond_top.pcm %S/Inputs/diamond_top.h
For modules, use a hash of the compiler version, language options, and target triple to separate modules built under different conditions. The hash is used to create a subdirectory in the module cache path where other invocations of the compiler (with the same version, language options, etc.) can find the precompiled modules. llvm-svn: 139662
2011-09-14 07:15:45 +08:00
// RUN: %clang_cc1 -fmodule-cache-path %T -fdisable-module-hash -emit-module -o %T/diamond_left.pcm %S/Inputs/diamond_left.h
// RUN: %clang_cc1 -fmodule-cache-path %T -fdisable-module-hash -emit-module -o %T/diamond_right.pcm %S/Inputs/diamond_right.h
// RUN: %clang_cc1 -fmodule-cache-path %T -fdisable-module-hash -emit-module -o %T/diamond_bottom.pcm %S/Inputs/diamond_bottom.h
// RUN: %clang_cc1 -fmodule-cache-path %T -fdisable-module-hash %s -verify