maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/SemaCXX/overloaded-builtin-operator...

80 lines
1.5 KiB
C++
Raw Normal View History

Implement support for operator overloading using candidate operator functions for built-in operators, e.g., the builtin bool operator==(int const*, int const*) can be used for the expression "x1 == x2" given: struct X { operator int const*(); } x1, x2; The scheme for handling these built-in operators is relatively simple: for each candidate required by the standard, create a special kind of candidate function for the built-in. If overload resolution picks the built-in operator, we perform the appropriate conversions on the arguments and then let the normal built-in operator take care of it. There may be some optimization opportunity left: if we can reduce the number of built-in operator overloads we generate, overload resolution for these cases will go faster. However, one must be careful when doing this: GCC generates too few operator overloads in our little test program, and fails to compile it because none of the overloads it generates match. Note that we only support operator overload for non-member binary operators at the moment. The other operators will follow. As part of this change, ImplicitCastExpr can now be an lvalue. llvm-svn: 59148
2008-11-13 01:17:38 +08:00
// RUN: clang -fsyntax-only -verify %s
struct yes;
struct no;
struct Short {
operator short();
};
struct Long {
operator long();
};
Built-in equality and relational operators have return type "bool" in C++, not "int". Fix a typo in the promotion of enumeration types that was causing some integral promotions to look like integral conversions (leading to extra ambiguities in overload resolution). Check for "acceptable" overloaded operators based on the types of the arguments. This is a somewhat odd check that is specified by the standard, but I can't see why it actually matters: the overload candidates it suppresses don't seem like they would ever be picked as the best candidates. llvm-svn: 59583
2008-11-19 11:25:36 +08:00
enum E1 { };
struct Enum1 {
operator E1();
};
enum E2 { };
struct Enum2 {
operator E2();
};
Implement support for operator overloading using candidate operator functions for built-in operators, e.g., the builtin bool operator==(int const*, int const*) can be used for the expression "x1 == x2" given: struct X { operator int const*(); } x1, x2; The scheme for handling these built-in operators is relatively simple: for each candidate required by the standard, create a special kind of candidate function for the built-in. If overload resolution picks the built-in operator, we perform the appropriate conversions on the arguments and then let the normal built-in operator take care of it. There may be some optimization opportunity left: if we can reduce the number of built-in operator overloads we generate, overload resolution for these cases will go faster. However, one must be careful when doing this: GCC generates too few operator overloads in our little test program, and fails to compile it because none of the overloads it generates match. Note that we only support operator overload for non-member binary operators at the moment. The other operators will follow. As part of this change, ImplicitCastExpr can now be an lvalue. llvm-svn: 59148
2008-11-13 01:17:38 +08:00
yes& islong(long);
Built-in equality and relational operators have return type "bool" in C++, not "int". Fix a typo in the promotion of enumeration types that was causing some integral promotions to look like integral conversions (leading to extra ambiguities in overload resolution). Check for "acceptable" overloaded operators based on the types of the arguments. This is a somewhat odd check that is specified by the standard, but I can't see why it actually matters: the overload candidates it suppresses don't seem like they would ever be picked as the best candidates. llvm-svn: 59583
2008-11-19 11:25:36 +08:00
yes& islong(unsigned long); // FIXME: shouldn't be needed
Implement support for operator overloading using candidate operator functions for built-in operators, e.g., the builtin bool operator==(int const*, int const*) can be used for the expression "x1 == x2" given: struct X { operator int const*(); } x1, x2; The scheme for handling these built-in operators is relatively simple: for each candidate required by the standard, create a special kind of candidate function for the built-in. If overload resolution picks the built-in operator, we perform the appropriate conversions on the arguments and then let the normal built-in operator take care of it. There may be some optimization opportunity left: if we can reduce the number of built-in operator overloads we generate, overload resolution for these cases will go faster. However, one must be careful when doing this: GCC generates too few operator overloads in our little test program, and fails to compile it because none of the overloads it generates match. Note that we only support operator overload for non-member binary operators at the moment. The other operators will follow. As part of this change, ImplicitCastExpr can now be an lvalue. llvm-svn: 59148
2008-11-13 01:17:38 +08:00
no& islong(int);
Built-in equality and relational operators have return type "bool" in C++, not "int". Fix a typo in the promotion of enumeration types that was causing some integral promotions to look like integral conversions (leading to extra ambiguities in overload resolution). Check for "acceptable" overloaded operators based on the types of the arguments. This is a somewhat odd check that is specified by the standard, but I can't see why it actually matters: the overload candidates it suppresses don't seem like they would ever be picked as the best candidates. llvm-svn: 59583
2008-11-19 11:25:36 +08:00
void f(Short s, Long l, Enum1 e1, Enum2 e2) {
Implement support for operator overloading using candidate operator functions for built-in operators, e.g., the builtin bool operator==(int const*, int const*) can be used for the expression "x1 == x2" given: struct X { operator int const*(); } x1, x2; The scheme for handling these built-in operators is relatively simple: for each candidate required by the standard, create a special kind of candidate function for the built-in. If overload resolution picks the built-in operator, we perform the appropriate conversions on the arguments and then let the normal built-in operator take care of it. There may be some optimization opportunity left: if we can reduce the number of built-in operator overloads we generate, overload resolution for these cases will go faster. However, one must be careful when doing this: GCC generates too few operator overloads in our little test program, and fails to compile it because none of the overloads it generates match. Note that we only support operator overload for non-member binary operators at the moment. The other operators will follow. As part of this change, ImplicitCastExpr can now be an lvalue. llvm-svn: 59148
2008-11-13 01:17:38 +08:00
// C++ [over.built]p12
(void)static_cast<yes&>(islong(s + l));
(void)static_cast<no&>(islong(s + s));
// C++ [over.built]p17
(void)static_cast<yes&>(islong(s % l));
(void)static_cast<yes&>(islong(l << s));
(void)static_cast<no&>(islong(s << l));
Built-in equality and relational operators have return type "bool" in C++, not "int". Fix a typo in the promotion of enumeration types that was causing some integral promotions to look like integral conversions (leading to extra ambiguities in overload resolution). Check for "acceptable" overloaded operators based on the types of the arguments. This is a somewhat odd check that is specified by the standard, but I can't see why it actually matters: the overload candidates it suppresses don't seem like they would ever be picked as the best candidates. llvm-svn: 59583
2008-11-19 11:25:36 +08:00
(void)static_cast<yes&>(islong(e1 % l));
// FIXME: should pass (void)static_cast<no&>(islong(e1 % e2));
Implement support for operator overloading using candidate operator functions for built-in operators, e.g., the builtin bool operator==(int const*, int const*) can be used for the expression "x1 == x2" given: struct X { operator int const*(); } x1, x2; The scheme for handling these built-in operators is relatively simple: for each candidate required by the standard, create a special kind of candidate function for the built-in. If overload resolution picks the built-in operator, we perform the appropriate conversions on the arguments and then let the normal built-in operator take care of it. There may be some optimization opportunity left: if we can reduce the number of built-in operator overloads we generate, overload resolution for these cases will go faster. However, one must be careful when doing this: GCC generates too few operator overloads in our little test program, and fails to compile it because none of the overloads it generates match. Note that we only support operator overload for non-member binary operators at the moment. The other operators will follow. As part of this change, ImplicitCastExpr can now be an lvalue. llvm-svn: 59148
2008-11-13 01:17:38 +08:00
}
struct ShortRef {
operator short&();
};
struct LongRef {
operator volatile long&();
};
void g(ShortRef sr, LongRef lr) {
// C++ [over.built]p18
short& sr1 = (sr *= lr);
volatile long& lr1 = (lr *= sr);
// C++ [over.built]p22
short& sr2 = (sr %= lr);
volatile long& lr2 = (lr <<= sr);
bool b1 = (sr && lr) || (sr || lr);
}
struct VolatileIntPtr {
operator int volatile *();
};
struct ConstIntPtr {
operator int const *();
};
void test_with_ptrs(VolatileIntPtr vip, ConstIntPtr cip, ShortRef sr) {
#if 0
// FIXME: Enable these tests once we have operator overloading for
// operator[].
const int& cir1 = cip[sr];
const int& cir2 = sr[cip];
volatile int& vir1 = vip[sr];
volatile int& vir2 = sr[vip];
#endif
bool b1 = (vip == cip);
long p1 = vip - cip;
}