hanchenye-llvm-project/clang/test/SemaObjCXX/message.mm

93 lines
1.6 KiB
Plaintext
Raw Normal View History

// RUN: %clang_cc1 -fsyntax-only -verify %s
@interface I1
- (int*)method;
@end
@implementation I1
- (int*)method {
struct x { };
Rework the Parser-Sema interaction for Objective-C message sends. Major changes include: - Expanded the interface from two actions (ActOnInstanceMessage, ActOnClassMessage), where ActOnClassMessage also handled sends to "super" by checking whether the identifier was "super", to three actions (ActOnInstanceMessage, ActOnClassMessage, ActOnSuperMessage). Code completion has the same changes. - The parser now resolves the type to which we are sending a class message, so ActOnClassMessage now accepts a TypeTy* (rather than an IdentifierInfo *). This opens the door to more interesting types (for Objective-C++ support). - Split ActOnInstanceMessage and ActOnClassMessage into parser action functions (with their original names) and semantic functions (BuildInstanceMessage and BuildClassMessage, respectively). At present, this split is onyl used by ActOnSuperMessage, which decides which kind of super message it has and forwards to the appropriate Build*Message. In the future, Build*Message will be used by template instantiation. - Use getObjCMessageKind() within the disambiguation of Objective-C message sends vs. array designators. Two notes about substandard bits in this patch: - There is some redundancy in the code in ParseObjCMessageExpr and ParseInitializerWithPotentialDesignator; this will be addressed shortly by centralizing the mapping from identifiers to type names for the message receiver. - There is some #if 0'd code that won't likely ever be used---it handles the use of 'super' in methods whose class does not have a superclass---but could be used to model GCC's behavior more closely. This code will die in my next check-in, but I want it in Subversion. llvm-svn: 102021
2010-04-22 03:57:20 +08:00
[x method]; // expected-error{{receiver type 'x' is not an Objective-C class}}
return 0;
}
@end
typedef struct { int x; } ivar;
@interface I2 {
id ivar;
}
- (int*)method;
+ (void)method;
@end
struct I2_holder {
I2_holder();
I2 *get();
};
I2 *operator+(I2_holder, int);
@implementation I2
- (int*)method {
[ivar method];
// Test instance messages that start with a simple-type-specifier.
[I2_holder().get() method];
[I2_holder().get() + 17 method];
return 0;
}
+ (void)method {
Rework the Parser-Sema interaction for Objective-C message sends. Major changes include: - Expanded the interface from two actions (ActOnInstanceMessage, ActOnClassMessage), where ActOnClassMessage also handled sends to "super" by checking whether the identifier was "super", to three actions (ActOnInstanceMessage, ActOnClassMessage, ActOnSuperMessage). Code completion has the same changes. - The parser now resolves the type to which we are sending a class message, so ActOnClassMessage now accepts a TypeTy* (rather than an IdentifierInfo *). This opens the door to more interesting types (for Objective-C++ support). - Split ActOnInstanceMessage and ActOnClassMessage into parser action functions (with their original names) and semantic functions (BuildInstanceMessage and BuildClassMessage, respectively). At present, this split is onyl used by ActOnSuperMessage, which decides which kind of super message it has and forwards to the appropriate Build*Message. In the future, Build*Message will be used by template instantiation. - Use getObjCMessageKind() within the disambiguation of Objective-C message sends vs. array designators. Two notes about substandard bits in this patch: - There is some redundancy in the code in ParseObjCMessageExpr and ParseInitializerWithPotentialDesignator; this will be addressed shortly by centralizing the mapping from identifiers to type names for the message receiver. - There is some #if 0'd code that won't likely ever be used---it handles the use of 'super' in methods whose class does not have a superclass---but could be used to model GCC's behavior more closely. This code will die in my next check-in, but I want it in Subversion. llvm-svn: 102021
2010-04-22 03:57:20 +08:00
[ivar method]; // expected-error{{receiver type 'ivar' (aka 'ivar') is not an Objective-C class}}
}
@end
// Class message sends
@interface I3
+ (int*)method;
@end
@interface I4 : I3
+ (int*)otherMethod;
@end
template<typename T>
struct identity {
typedef T type;
};
@implementation I4
+ (int *)otherMethod {
// Test class messages that use non-trivial simple-type-specifiers
// or typename-specifiers.
if (false) {
if (true)
return [typename identity<I3>::type method];
return [::I3 method];
}
int* ip1 = {[super method]};
int* ip2 = {[::I3 method]};
int* ip3 = {[typename identity<I3>::type method]};
int* ip4 = {[typename identity<I2_holder>::type().get() method]};
int array[5] = {[3] = 2};
return [super method];
}
@end
struct String {
String(const char *);
};
struct MutableString : public String { };
// C++-specific parameter types
@interface I5
- method:(const String&)str1 other:(String&)str2;
@end
void test_I5(I5 *i5, String s) {
[i5 method:"hello" other:s];
}