summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.h
Commit message (Collapse)AuthorAgeFilesLines
* Move Sema's headers into include/clang/Sema, renaming a few along the way.Douglas Gregor2010-08-121-617/+0
| | | | llvm-svn: 110945
* An identity conversion is better than any non-identityDouglas Gregor2010-05-231-0/+6
| | | | | | conversion. Fixes PR7095. llvm-svn: 104476
* Implement C++ support for vector and extended vector types. ThisDouglas Gregor2010-05-181-0/+2
| | | | | | | | | | involves extending implicit conversion sequences to model vector conversions and vector splats, along with teaching the C++ conditional operator-checking code about vector types. Fixes <rdar://problem/7983501>. llvm-svn: 104081
* When printing an overload candidate that failed due to SFINAE, print aDouglas Gregor2010-05-081-0/+4
| | | | | | | | | | | specific message that includes the template arguments, e.g., test/SemaTemplate/overload-candidates.cpp:27:20: note: candidate template ignored: substitution failure [with T = int *] typename T::type get_type(const T&); // expected-note{{candidate ... ^ llvm-svn: 103348
* Minor cleanup, and ban copying of OverloadCandidateSets. NoDouglas Gregor2010-05-081-0/+4
| | | | | | functionality change. llvm-svn: 103342
* When printing a non-viable overload candidate that failed due toDouglas Gregor2010-05-081-6/+23
| | | | | | | | | | | | conflicting deduced template argument values, give a more specific reason along with those values, e.g., test/SemaTemplate/overload-candidates.cpp:4:10: note: candidate template ignored: deduced conflicting types for parameter 'T' ('int' vs. 'long') const T& min(const T&, const T&); ^ llvm-svn: 103339
* Improve our handling of user-defined conversions as part of overloadDouglas Gregor2010-04-171-0/+27
| | | | | | | | | | | | | | | | | 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
* Implement C++ [over.ics.user]p3, which restricts the final conversionDouglas Gregor2010-04-121-1/+5
| | | | | | | | | from a conversion function template specialization to one of exact match rank. We only know how to test this in C++0x with default function template arguments, but it's also in the C++03 spec. Fixes PR6285. llvm-svn: 101089
* Fixed 80-cols violationAlexis Hunt2010-04-071-1/+1
| | | | llvm-svn: 100704
* Remember the "found declaration" for an overload candidate, which is theJohn McCall2010-03-191-8/+6
| | | | | | | | | | | | | | | | entity (if applicable) which was actually looked up. If a candidate was found via a using declaration, this is the UsingShadowDecl; otherwise, if the candidate is template specialization, this is the template; otherwise, this is the function. The point of this exercise is that "found declarations" are the entities we do access control for, not their underlying declarations. Broadly speaking, this patch fixes access control for using declarations. There is a *lot* of redundant code calling into the overload-resolution APIs; we really ought to clean that up. llvm-svn: 98945
* Warn about the deprecated string literal -> char* conversion. Fixes PR6428.Douglas Gregor2010-02-281-1/+1
| | | | llvm-svn: 97404
* Add a new conversion rank to classify conversions between complex and scalarChandler Carruth2010-02-251-4/+5
| | | | | | | | types. Rank these conversions below other conversions. This allows overload resolution when the only distinction is between a complex and scalar type. It also brings the complex overload resolutin in line with GCC's. llvm-svn: 97128
* Catch more uses of uninitialized implicit conversion sequences.John McCall2010-02-251-14/+43
| | | | | | | When diagnosing bad conversions, skip the conversion for ignored object arguments. Fixes PR 6398. llvm-svn: 97090
* Thread a source location into the template-argument deduction routines. ThereJohn McCall2010-02-081-1/+6
| | | | | | | may be some other places that could take advantage of this new information, but I haven't really looked yet. llvm-svn: 95600
* Note that an overload candidate was non-viable because template argumentJohn McCall2010-02-011-5/+19
| | | | | | | deduction failed. Right now there's a very vague diagnostic for most cases and a good diagnostic for incomplete deduction. llvm-svn: 94988
* Fix a major oversight in the comparison of standard conversionDouglas Gregor2010-01-271-6/+17
| | | | | | | | | | | | | | sequences, where we would occasionally determine (incorrectly) that one standard conversion sequence was a proper subset of another when, in fact, they contained completely incomparable conversions. This change records the types in each step within a standard conversion sequence, so that we can check the specific comparison types to determine when one sequence is a proper subset of the other. Fixes this testcase (thanks, Anders!), which was distilled from PR6095 (also thanks to Anders). llvm-svn: 94660
* Pass access specifiers around in overload resolution.John McCall2010-01-261-0/+8
| | | | llvm-svn: 94485
* During overload resolution diagnostics, sort non-viable candidates by the ↵John McCall2010-01-231-1/+10
| | | | | | | | | | | | | quality of their conversions. To make this work, fill out all conversions for all candidates (but only when diagnosing overload failure). Split out a few cases from ovl_fail_bad_conversion which didn't actually involve a failed argument conversion. I'm pretty sure this is not a well-founded ordering, but I'm not sure it matters. llvm-svn: 94283
* Record some basic information about bad conversion sequences. Use thatJohn McCall2010-01-131-1/+62
| | | | | | | information to feed diagnostics instead of regenerating it. Much room for improvement here, but fixes some unfortunate problems reporting on method calls. llvm-svn: 93316
* Introduce a specific representation for the ambiguous implicit conversionJohn McCall2010-01-121-6/+117
| | | | | | | sequence. Lots of small relevant changes. Fixes some serious problems with ambiguous conversions; also possibly improves associated diagnostics. llvm-svn: 93214
* Reimplement reference initialization (C++ [dcl.init.ref]) using theDouglas Gregor2009-12-091-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | new notion of an "initialization sequence", which encapsulates the computation of the initialization sequence along with diagnostic information and the capability to turn the computed sequence into an expression. At present, I've only switched one CheckReferenceInit callers over to this new mechanism; more will follow. Aside from (hopefully) being much more true to the standard, the diagnostics provided by this reference-initialization code are a bit better than before. Some examples: p5-var.cpp:54:12: error: non-const lvalue reference to type 'struct Derived' cannot bind to a value of unrelated type 'struct Base' Derived &dr2 = b; // expected-error{{non-const lvalue reference to ... ^ ~ p5-var.cpp:55:9: error: binding of reference to type 'struct Base' to a value of type 'struct Base const' drops qualifiers Base &br3 = bc; // expected-error{{drops qualifiers}} ^ ~~ p5-var.cpp:57:15: error: ambiguous conversion from derived class 'struct Diamond' to base class 'struct Base': struct Diamond -> struct Derived -> struct Base struct Diamond -> struct Derived2 -> struct Base Base &br5 = diamond; // expected-error{{ambiguous conversion from ... ^~~~~~~ p5-var.cpp:59:9: error: non-const lvalue reference to type 'long' cannot bind to a value of unrelated type 'int' long &lr = i; // expected-error{{non-const lvalue reference to type ... ^ ~ p5-var.cpp:74:9: error: non-const lvalue reference to type 'struct Base' cannot bind to a temporary of type 'struct Base' Base &br1 = Base(); // expected-error{{non-const lvalue reference to ... ^ ~~~~~~ p5-var.cpp:102:9: error: non-const reference cannot bind to bit-field 'i' int & ir1 = (ib.i); // expected-error{{non-const reference cannot ... ^ ~~~~~~ p5-var.cpp:98:7: note: bit-field is declared here int i : 17; // expected-note{{bit-field is declared here}} ^ llvm-svn: 90992
* Implemented an implicit conversion from "noreturn" function types (andDouglas Gregor2009-12-091-0/+1
| | | | | | | | | | | | | | pointers thereof) to their corresponding non-noreturn function types. This conversion is considered an exact match for overload-resolution purposes. Note that we are a little more strict that GCC is, because we encode noreturn in the type system, but that's a Good Thing (TM) because it does not allow us to pretend that potentially-returning function pointers are non-returning function pointers. Fxies PR5620. llvm-svn: 90913
* This patch implements Sema for clause 13.3.3.1p4.Fariborz Jahanian2009-11-061-0/+8
| | | | | | | It has to do with vararg constructors used as conversion functions. Code gen needs work. This is WIP. llvm-svn: 86207
* Don't allow the same function to enter the overload candidate setDouglas Gregor2009-09-281-1/+10
| | | | | | | multiple times. This requires to be more careful about re-adding candidates cached from the function template definition. llvm-svn: 82967
* Produce detailed diagnostics when overloadFariborz Jahanian2009-09-231-1/+5
| | | | | | | resolution failed to select a candidate due to ambiguity in type conversion function selection. llvm-svn: 82596
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-10/+10
| | | | llvm-svn: 81346
* Fix a crash bug when comparing overload quality of conversion operators with ↵Sebastian Redl2009-04-161-1/+1
| | | | | | | | | | | conversion constructors. Remove an atrocious amount of trailing whitespace in the overloaded operator mangler. Sorry, couldn't help myself. Change the DeclType parameter of Sema::CheckReferenceInit to be passed by value instead of reference. It wasn't changed anywhere. Let the parser handle C++'s irregular grammar around assignment-expression and conditional-expression. And finally, the reason for all this stuff: implement C++ semantics for the conditional operator. The implementation is complete except for determining lvalueness. llvm-svn: 69299
* Reintroduce r67870 (rval ref overloading), since I can't reproduce any test ↵Sebastian Redl2009-03-291-0/+4
| | | | | | failures on i386 or x86_64. If this fails for someone, please contact me. llvm-svn: 67999
* Revert Sebastian's rvalue patch (r67870) since it caused test failures inAnders Carlsson2009-03-281-4/+0
| | | | | | | | SemaCXX//overload-member-call.cpp SemaCXX//overloaded-operator.cpp SemaTemplate//instantiate-method.cpp llvm-svn: 67912
* Better overload resolution for rvalue references.Sebastian Redl2009-03-271-0/+4
| | | | llvm-svn: 67870
* Introduce _Complex conversions into the function overloadingDouglas Gregor2009-02-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | system. Since C99 doesn't have overloading and C++ doesn't have _Complex, there is no specification for this. Here's what I think makes sense. Complex conversions come in several flavors: - Complex promotions: a complex -> complex conversion where the underlying real-type conversion is a floating-point promotion. GCC seems to call this a promotion, EDG does something else. This is given "promotion" rank for determining the best viable function. - Complex conversions: a complex -> complex conversion that is not a complex promotion. This is given "conversion" rank for determining the best viable function. - Complex-real conversions: a real -> complex or complex -> real conversion. This is given "conversion" rank for determining the best viable function. These rules are the same for C99 (when using the "overloadable" attribute) and C++. However, there is one difference in the handling of floating-point promotions: in C99, float -> long double and double -> long double are considered promotions (so we give them "promotion" rank), while C++ considers these conversions ("conversion" rank). llvm-svn: 64343
* Initial implementation of function overloading in C.Douglas Gregor2009-02-111-15/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a new attribute, "overloadable", that enables C++ function overloading in C. The attribute can only be added to function declarations, e.g., int *f(int) __attribute__((overloadable)); If the "overloadable" attribute exists on a function with a given name, *all* functions with that name (and in that scope) must have the "overloadable" attribute. Sets of overloaded functions with the "overloadable" attribute then follow the normal C++ rules for overloaded functions, e.g., overloads must have different parameter-type-lists from each other. When calling an overloaded function in C, we follow the same overloading rules as C++, with three extensions to the set of standard conversions: - A value of a given struct or union type T can be converted to the type T. This is just the identity conversion. (In C++, this would go through a copy constructor). - A value of pointer type T* can be converted to a value of type U* if T and U are compatible types. This conversion has Conversion rank (it's considered a pointer conversion in C). - A value of type T can be converted to a value of type U if T and U are compatible (and are not both pointer types). This conversion has Conversion rank (it's considered to be a new kind of conversion unique to C, a "compatible" conversion). Known defects (and, therefore, next steps): 1) The standard-conversion handling does not understand conversions involving _Complex or vector extensions, so it is likely to get these wrong. We need to add these conversions. 2) All overloadable functions with the same name will have the same linkage name, which means we'll get a collision in the linker (if not sooner). We'll need to mangle the names of these functions. llvm-svn: 64336
* Add support for calls to overloaded member functions. Things to note:Douglas Gregor2008-12-221-0/+9
| | | | | | | | | | | | - Overloading has to cope with having both static and non-static member functions in the overload set. - The call may or may not have an implicit object argument, depending on the syntax (x.f() vs. f()) and the context (static vs. non-static member function). - We now generate MemberExprs for implicit member access expression. - We now cope with mutable whenever we're building MemberExprs. llvm-svn: 61329
* Allow downcasts of pointers to Objective-C interfaces, with aDouglas Gregor2008-12-191-0/+4
| | | | | | | warning. This matches GCC's behavior and addresses <rdar://problem/6458293>. llvm-svn: 61246
* Implement the rest of C++ [over.call.object], which permits the objectDouglas Gregor2008-11-191-2/+13
| | | | | | | | | | being called to be converted to a reference-to-function, pointer-to-function, or reference-to-pointer-to-function. This is done through "surrogate" candidate functions that model the conversions from the object to the function (reference/pointer) and the conversions in the arguments. llvm-svn: 59674
* Implement support for operator overloading using candidate operatorDouglas Gregor2008-11-121-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Initial, partially-baked support for implicit user-defined conversions by ↵Douglas Gregor2008-11-071-0/+6
| | | | | | conversion functions llvm-svn: 58870
* Standard conversion sequences now have a CopyConstructor field, toDouglas Gregor2008-11-031-0/+8
| | | | | | | | | | | | | | | cope with the case where a user-defined conversion is actually a copy construction, and therefore can be compared against other standard conversion sequences. While I called this a hack before, now I'm convinced that it's the right way to go. Compare overloads based on derived-to-base conversions that invoke copy constructors. Suppress user-defined conversions when attempting to call a user-defined conversion. llvm-svn: 58629
* Implement basic support for converting constructors in user-defined Douglas Gregor2008-10-311-0/+1
| | | | | | | | | | | | | conversions. Notes: - Overload resolution for converting constructors need to prohibit user-defined conversions (hence, the test isn't -verify safe yet). - We still use hacks for conversions from a class type to itself. This will be the case until we start implicitly declaring the appropriate special member functions. (That's next on my list) llvm-svn: 58513
* Implement overloading rules for reference bindingDouglas Gregor2008-10-291-11/+9
| | | | llvm-svn: 58381
* Tweak Sema::CheckReferenceInit so that it (optionally) computes an Douglas Gregor2008-10-291-4/+15
| | | | | | | | | | | ImplicitConversionSequence and, when doing so, following the specific rules of [over.best.ics]. The computation of the implicit conversion sequences implements C++ [over.ics.ref], but we do not (yet) have ranking for implicit conversion sequences that use reference binding. llvm-svn: 58357
* Add support for conversions from a pointer-to-derived to aDouglas Gregor2008-10-231-4/+4
| | | | | | | | | | | | pointer-to-base. Also, add overload ranking for pointer conversions (for both pointer-to-void and derived-to-base pointer conversions). Note that we do not yet diagnose derived-to-base pointer conversion errors that stem from ambiguous or inacessible base classes. These aren't handled during overload resolution; rather, when the conversion is actually used we go ahead and diagnose the error. llvm-svn: 58017
* Implement ranking of standard conversion sequences by their qualificationDouglas Gregor2008-10-221-3/+3
| | | | | | | | | | | | conversions (e.g., comparing int* -> const int* against int* -> const volatile int*); see C++ 13.3.3.2p3 bullet 3. Add Sema::UnwrapSimilarPointerTypes to simplify the control flow of IsQualificationConversion and CompareQualificationConversion (and fix the handling of the int* -> volatile int* conversion in the former). llvm-svn: 57978
* Preliminary support for function overloadingDouglas Gregor2008-10-211-0/+199
llvm-svn: 57909
OpenPOWER on IntegriCloud