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/Inputs/def.h

28 lines
238 B
C
Raw Normal View History

When inferring a submodule ID during module creation, look up the include stack to find the first file that is known to be part of the module. This copes with situations where the module map doesn't completely specify all of the headers that are involved in the module, which can come up when there are very strange #include_next chains (e.g., with weird compiler/stdlib headers like stdarg.h or float.h). llvm-svn: 147662
2012-01-07 01:19:32 +08:00
#include "def-include.h"
Diagnose cases where the definition of a particular type is required, is known (to Clang), but is not visible because the module has not yet been imported. llvm-svn: 147436
2012-01-03 01:18:37 +08:00
@interface A {
@public
int ivar;
}
When name lookup comes across a declaration that is in a module that is not visible, look for any previous declarations of that entity that might be visible. llvm-svn: 146563
2011-12-15 00:03:29 +08:00
@end
Ensure that type definitions present in just-loaded modules are visible. The basic problem here is that a given translation unit can use forward declarations to form pointers to a given type, say, class X; X *x; and then import a module that includes a definition of X: import XDef; We will then fail when attempting to access a member of X, e.g., x->method() because the AST reader did not know to look for a default of a class named X within the new module. This implementation is a bit of a C-centric hack, because the only definitions that can have this property are enums, structs, unions, Objective-C classes, and Objective-C protocols, and all of those are either visible at the top-level or can't be defined later. Hence, we can use the out-of-date-ness of the name and the identifier-update mechanism to force the update. In C++, we will not be so lucky, and will need a more advanced solution, because the definitions could be in namespaces defined in two different modules, e.g., // module 1 namespace N { struct X; } // module 2 namespace N { struct X { /* ... */ }; } One possible implementation here is for C++ to extend the information associated with each identifier table to include the declaration IDs of any definitions associated with that name, regardless of context. We would have to eagerly load those definitions. llvm-svn: 174794
2013-02-09 09:35:03 +08:00
@interface Def
- defMethod;
@end
When name lookup comes across a declaration that is in a module that is not visible, look for any previous declarations of that entity that might be visible. llvm-svn: 146563
2011-12-15 00:03:29 +08:00
Ensure that type definitions present in just-loaded modules are visible. The basic problem here is that a given translation unit can use forward declarations to form pointers to a given type, say, class X; X *x; and then import a module that includes a definition of X: import XDef; We will then fail when attempting to access a member of X, e.g., x->method() because the AST reader did not know to look for a default of a class named X within the new module. This implementation is a bit of a C-centric hack, because the only definitions that can have this property are enums, structs, unions, Objective-C classes, and Objective-C protocols, and all of those are either visible at the top-level or can't be defined later. Hence, we can use the out-of-date-ness of the name and the identifier-update mechanism to force the update. In C++, we will not be so lucky, and will need a more advanced solution, because the definitions could be in namespaces defined in two different modules, e.g., // module 1 namespace N { struct X; } // module 2 namespace N { struct X { /* ... */ }; } One possible implementation here is for C++ to extend the information associated with each identifier table to include the declaration IDs of any definitions associated with that name, regardless of context. We would have to eagerly load those definitions. llvm-svn: 174794
2013-02-09 09:35:03 +08:00
#ifdef __cplusplus
class Def2 {
public:
void func();
};
C++ modules: fix a bug where loading a declaration with some name would prevent name lookup from lazily deserializing the other declarations with the same name, by tracking a bit to indicate whether a name in a DeclContext might have additional external results. This also allows lazier reconciling of the lookup table if a module import adds decls to a pre-existing DC. However, this exposes a pre-existing bug, which causes a regression in test/Modules/decldef.mm: if we have a reference to a declaration, and a later-imported module adds a redeclaration, nothing causes us to load that redeclaration when we use or emit the reference (which can manifest as a reference to an undefined inline function, a use of an incomplete type, and so on). decldef.mm has been extended with an additional testcase which fails with or without this change. llvm-svn: 190293
2013-09-09 15:34:56 +08:00
namespace Def3NS {
class Def3 {
public:
void func();
};
}
Ensure that type definitions present in just-loaded modules are visible. The basic problem here is that a given translation unit can use forward declarations to form pointers to a given type, say, class X; X *x; and then import a module that includes a definition of X: import XDef; We will then fail when attempting to access a member of X, e.g., x->method() because the AST reader did not know to look for a default of a class named X within the new module. This implementation is a bit of a C-centric hack, because the only definitions that can have this property are enums, structs, unions, Objective-C classes, and Objective-C protocols, and all of those are either visible at the top-level or can't be defined later. Hence, we can use the out-of-date-ness of the name and the identifier-update mechanism to force the update. In C++, we will not be so lucky, and will need a more advanced solution, because the definitions could be in namespaces defined in two different modules, e.g., // module 1 namespace N { struct X; } // module 2 namespace N { struct X { /* ... */ }; } One possible implementation here is for C++ to extend the information associated with each identifier table to include the declaration IDs of any definitions associated with that name, regardless of context. We would have to eagerly load those definitions. llvm-svn: 174794
2013-02-09 09:35:03 +08:00
#endif