- 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
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
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
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
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
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
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
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
Douglas Gregor