summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/overloaded-builtin-operators.cpp
Commit message (Collapse)AuthorAgeFilesLines
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-241-3/+3
| | | | to the ambiguity, rather than noting all viable candidates.
* [Sema] Fix built-in decrement operator overload resolutionJan Korous2018-04-111-2/+16
| | | | | | | | | | | | | | | | | C++ [over.built] p4: "For every pair (T, VQ), where T is an arithmetic type other than bool, and VQ is either volatile or empty, there exist candidate operator functions of the form VQ T& operator--(VQ T&); T operator--(VQ T&, int); " The bool type is in position LastPromotedIntegralType in BuiltinOperatorOverloadBuilder::getArithmeticType::ArithmeticTypes, but addPlusPlusMinusMinusArithmeticOverloads() was expecting it at position 0. Differential Revision: https://reviews.llvm.org/D44988 rdar://problem/34255516 llvm-svn: 329804
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-1/+1
| | | | | | | | | | | | | | | | | | This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-1/+1
| | | | | | | | | | Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-1/+1
| | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
* [Lit Test] Updated 34 Lit tests to be C++11 compatible.Charles Li2015-11-171-2/+10
| | | | | | | Added expected diagnostics new to C++11. Expanded RUN line to: default, C++98/03 and C++11. llvm-svn: 253371
* clang/test: Remove "REQUIRES:LP64" in two tests. Each of them have explicit ↵NAKAMURA Takumi2012-12-071-1/+0
| | | | | | triple. llvm-svn: 169587
* Reject uses of __int128 on platforms that don't support it. Also move the uglyRichard Smith2012-11-291-1/+1
| | | | | | | 'getPointerWidth(0) >= 64' test to be a method on TargetInfo, ready to be properly cleaned up. llvm-svn: 168856
* clang/test: [PR8833] Introduce the feature "LP64" to suppress ↵NAKAMURA Takumi2012-09-121-0/+2
| | | | | | | | LLP64-incompatible tests. I think some of them could be rewritten to fit also LLP64. llvm-svn: 163699
* PR12964: __int128 and unsigned __int128 are promoted integral types, be sure toRichard Smith2012-06-101-1/+13
| | | | | | consider them when enumerating builtin operator candidates. llvm-svn: 158293
* When adding built-in operator candidates for overload resolutionDouglas Gregor2012-06-041-0/+19
| | | | | | | | involving 'restrict', place restrict on the pointer type rather than on the pointee type. Also make sure that we gather restrict from the pointer type. Fixes PR12854 and the major part of PR11093. llvm-svn: 157910
* Many of the built-in operator candidates introduced into overloadDouglas Gregor2011-01-051-0/+17
| | | | | | | resolution require that the pointed-to type be an object type, but we weren't filtering out non-object types. Do so, fixing PR7851. llvm-svn: 122853
* When producing overload candidates for binary built-in operators, keepDouglas Gregor2010-11-031-0/+20
| | | | | | | | | the sets of available conversions for the first and second arguments separate. This is apparently the indent of C++ [over.built], and reduces the number of overload candidates generated, eliminating some ambiguities. Fixes PR8477. llvm-svn: 118178
* Add an option -fshow-overloads=best|all to limit the number of overloadJeffrey Yasskin2010-06-111-2/+3
| | | | | | | candidates printed. We default to 'all'. At the moment, 'best' prints only the first 4 overloads, but we'll improve that over time. llvm-svn: 105815
* A built-in overload candidate is consider a non-template function whenDouglas Gregor2010-06-081-0/+11
| | | | | | | determining whether one overload candidate is better than another. Fixes PR7319. llvm-svn: 105642
* Improve the reporting of non-viable overload candidates by noting the reasonJohn McCall2010-01-131-2/+2
| | | | | | | | why the candidate is non-viable. There's a lot we can do to improve this, but it's a good start. Further improvements should probably be integrated with the bad-initialization reporting routines. llvm-svn: 93277
* Improve the diagnostics used to report implicitly-generated class membersJohn McCall2010-01-061-2/+2
| | | | | | | | | as parts of overload sets. Also, refer to constructors as 'constructors' rather than functions. Adjust a lot of tests. llvm-svn: 92832
* Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar2009-12-151-1/+1
| | | | | | | | | - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
* Always build a builtin operator expression for the __extension__ unary operator.Anders Carlsson2009-11-141-0/+3
| | | | llvm-svn: 88811
* For array pointee type, get its cvr qualifier fromFariborz Jahanian2009-11-091-0/+10
| | | | | | its element type. Fixes pr5432. llvm-svn: 86587
* Don't generate pointer types for void or base classes when findingDouglas Gregor2009-10-211-0/+25
| | | | | | | conversion types for builtin overloaded operator candidates; I misread this section in the standard the first time around. llvm-svn: 84788
* When overload resolution fails for an overloaded operator, show theDouglas Gregor2009-09-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | overload candidates (but not the built-in ones). We still rely on the underlying built-in semantic analysis to produce the initial diagnostic, then print the candidates following that diagnostic. One side advantage of this approach is that we can perform more validation of C++'s operator overloading with built-in candidates vs. the semantic analysis for those built-in operators: when there are no viable candidates, we know to expect an error from the built-in operator handling code. Otherwise, we are not modeling the built-in semantics properly within operator overloading. This is checked as: assert(Result.isInvalid() && "C++ binary operator overloading is missing candidates!"); if (Result.isInvalid()) PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false); The assert() catches cases where we're wrong in a +Asserts build. The "if" makes sure that, if this happens in a production clang (-Asserts), we still build the proper built-in operator and continue on our merry way. This is effectively what happened before this change, but we've added the assert() to catch more flies. llvm-svn: 83175
* Implement support for equality comparisons (!=, ==) of memberDouglas Gregor2009-08-241-2/+32
| | | | | | | | | | pointers, by extending the "composite pointer type" logic to include member pointer types. Introduce test cases for member pointer comparisons, including those that involve the builtin operator candidates implemented earlier. llvm-svn: 79925
* Avoid using the built-in type checker for assignment in C++ when classes are ↵Sebastian Redl2009-05-211-1/+1
| | | | | | involved. Patch by Vyacheslav Kononenko. llvm-svn: 72212
* Rename clang to clang-cc.Daniel Dunbar2009-03-241-1/+1
| | | | | | Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
* Add the proper restrictions on the left-hand argument of a built-inDouglas Gregor2009-01-131-0/+5
| | | | | | assignment operator candidate (C++ [over.match.oper]p4). llvm-svn: 62128
* Enable some more operator overloading tests, and don't look into an ↵Douglas Gregor2008-11-211-4/+0
| | | | | | identifier for functions that might not have one llvm-svn: 59818
* Support overloading of the subscript operator[], including support forDouglas Gregor2008-11-191-0/+4
| | | | | | | | | 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
* Added operator overloading for unary operators, post-increment, andDouglas Gregor2008-11-191-1/+39
| | | | | | | | | | | | | 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
* Built-in equality and relational operators have return type "bool" in C++,Douglas Gregor2008-11-191-1/+14
| | | | | | | | | | | | | | | | 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
* Implement support for operator overloading using candidate operatorDouglas Gregor2008-11-121-0/+66
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
OpenPOWER on IntegriCloud