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...

118 lines
2.2 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) {
Added operator overloading for unary operators, post-increment, and post-decrement, including support for generating all of the built-in operator candidates for these operators. C++ and C have different rules for the arguments to the builtin unary '+' and '-'. Implemented both variants in Sema::ActOnUnaryOp. In C++, pre-increment and pre-decrement return lvalues. Update Expr::isLvalue accordingly. llvm-svn: 59638
2008-11-19 23:42:04 +08:00
// C++ [over.built]p8
int i1 = +e1;
int i2 = -e2;
// C++ [over.built]p10:
int i3 = ~s;
bool b1 = !s;
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) {
Added operator overloading for unary operators, post-increment, and post-decrement, including support for generating all of the built-in operator candidates for these operators. C++ and C have different rules for the arguments to the builtin unary '+' and '-'. Implemented both variants in Sema::ActOnUnaryOp. In C++, pre-increment and pre-decrement return lvalues. Update Expr::isLvalue accordingly. llvm-svn: 59638
2008-11-19 23:42:04 +08:00
// C++ [over.built]p3
short s1 = sr++;
// C++ [over.built]p3
long l1 = lr--;
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]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 *();
};
Added operator overloading for unary operators, post-increment, and post-decrement, including support for generating all of the built-in operator candidates for these operators. C++ and C have different rules for the arguments to the builtin unary '+' and '-'. Implemented both variants in Sema::ActOnUnaryOp. In C++, pre-increment and pre-decrement return lvalues. Update Expr::isLvalue accordingly. llvm-svn: 59638
2008-11-19 23:42:04 +08:00
struct VolatileIntPtrRef {
operator int volatile *&();
};
struct ConstIntPtrRef {
operator int const *&();
};
void test_with_ptrs(VolatileIntPtr vip, ConstIntPtr cip, ShortRef sr,
VolatileIntPtrRef vipr, ConstIntPtrRef cipr) {
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
const int& cir1 = cip[sr];
const int& cir2 = sr[cip];
volatile int& vir1 = vip[sr];
volatile int& vir2 = sr[vip];
bool b1 = (vip == cip);
long p1 = vip - cip;
Added operator overloading for unary operators, post-increment, and post-decrement, including support for generating all of the built-in operator candidates for these operators. C++ and C have different rules for the arguments to the builtin unary '+' and '-'. Implemented both variants in Sema::ActOnUnaryOp. In C++, pre-increment and pre-decrement return lvalues. Update Expr::isLvalue accordingly. llvm-svn: 59638
2008-11-19 23:42:04 +08:00
// C++ [over.built]p5:
int volatile *vip1 = vipr++;
int const *cip1 = cipr++;
int volatile *&vipr1 = ++vipr;
int const *&cipr1 = --cipr;
// C++ [over.built]p6:
int volatile &ivr = *vip;
// C++ [over.built]p8:
int volatile *vip2 = +vip;
int i1 = +sr;
int i2 = -sr;
Support overloading of the subscript operator[], including support for built-in operator candidates. Test overloading of '&' and ','. In C++, a comma expression is an lvalue if its right-hand subexpression is an lvalue. Update Expr::isLvalue accordingly. llvm-svn: 59643
2008-11-20 01:17:41 +08:00
// C++ [over.built]p13:
int volatile &ivr2 = vip[17];
int const &icr2 = 17[cip];
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
}
Added operator overloading for unary operators, post-increment, and post-decrement, including support for generating all of the built-in operator candidates for these operators. C++ and C have different rules for the arguments to the builtin unary '+' and '-'. Implemented both variants in Sema::ActOnUnaryOp. In C++, pre-increment and pre-decrement return lvalues. Update Expr::isLvalue accordingly. llvm-svn: 59638
2008-11-19 23:42:04 +08:00