summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/user-defined-conversions.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Improve the error message when a function overload candidate is rejectedKaelyn Uhrain2012-06-191-1/+1
| | | | | | | | | | | | | | | | | because it expects a reference and receives a non-l-value. For example, given: int foo(int &); template<int x> void b() { foo(x); } clang will now print "expects an l-value for 1st argument" instead of "no known conversion from 'int' to 'int &' for 1st argument". The change in wording (and associated code to detect the case) was prompted by comment #5 in PR3104, and should be the last bit of work needed for the bug. llvm-svn: 158691
* When performing a user-defined conversion via a constructor, be sureDouglas Gregor2011-10-101-0/+15
| | | | | | | to check whether the constructor is accessible. Fixes <rdar://problem/10202900>. llvm-svn: 141588
* Improve our handling of user-defined conversions as part of overloadDouglas Gregor2010-04-171-0/+15
| | | | | | | | | | | | | | | | | resolution. There are two sources of problems involving user-defined conversions that this change eliminates, along with providing simpler interfaces for checking implicit conversions: - It eliminates a case of infinite recursion found in Boost. - It eliminates the search for the constructor needed to copy a temporary generated by an implicit conversion from overload resolution. Overload resolution assumes that, if it gets a value of the parameter's class type (or a derived class thereof), there is a way to copy if... even if there isn't. We now model this properly. llvm-svn: 101680
* 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
* Rename clang to clang-cc.Daniel Dunbar2009-03-241-1/+1
| | | | | | Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
* Steve set me straight on this one. GCC was right, EDG was wrong: theDouglas Gregor2009-02-021-1/+1
| | | | | | | | | | direct-initialization following a user-defined conversion can select any constructor; it just can't employ any user-defined conversions. So we ban those conversions and classify the constructor call based on the relationship between the "from" and "to" types in the conversion. llvm-svn: 63554
* Improve our handling of the second step in a user-defined conversionDouglas Gregor2009-01-301-0/+32
| | | | | | | | | | | | | | sequence. Previously, we weren't permitting the second step to call copy constructors, which left user-defined conversion sequences surprisingly broken. Now, we perform overload resolution among all of the constructors, but only accept the result if it makes the conversion a standard conversion. Note that this behavior is different from both GCC and EDG (which don't agree with each other, either); I've submitted a core issue on the matter. llvm-svn: 63450
* Allow user-defined conversions during reference bindingDouglas Gregor2008-11-101-0/+15
| | | | llvm-svn: 58988
* Initial, partially-baked support for implicit user-defined conversions by ↵Douglas Gregor2008-11-071-0/+22
conversion functions llvm-svn: 58870
OpenPOWER on IntegriCloud