[cfe-commits] r58357 - in /cfe/trunk: lib/Sema/Sema.h lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaExpr.cpp lib/Sema/SemaOverload.cpp lib/Sema/SemaOverload.h test/SemaCXX/overload-call.cpp

[Doug Gregor]

On Wed, Oct 29, 2008 at 3:52 PM, Sebastian Redl
<sebastian.redl at getdesigned.at> wrote:
> Douglas Gregor wrote:
>>
>> Author: dgregor
>> Date: Tue Oct 28 21:00:59 2008
>> New Revision: 58357
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=58357&view=rev
>> Log:
>> Tweak Sema::CheckReferenceInit so that it (optionally) computes an
>> 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.
>>
>>
>> @@ -731,17 +733,27 @@
>>  /// list), and DeclType is the type of the declaration. When Complain
>>  /// is true, this routine will produce diagnostics (and return true)
>>  /// when the declaration cannot be initialized with the given
>> -/// initializer. When Complain is false, this routine will return true
>> -/// when the initialization cannot be performed, but will not produce
>> -/// any diagnostics or alter Init.
>> -bool Sema::CheckReferenceInit(Expr *&Init, QualType &DeclType, bool
>> Complain) {
>> +/// initializer. When ICS is non-null, this routine will compute the
>> +/// implicit conversion sequence according to C++ [over.ics.ref] and
>> +/// will not produce any diagnostics; when ICS is null, it will emit
>> +/// diagnostics when any errors are found.
>> +bool +Sema::CheckReferenceInit(Expr *&Init, QualType &DeclType, +
>>                 ImplicitConversionSequence *ICS) {
>>
>
> Am I the only one for whom this is corrupted even after a clean checkout?

That's odd; it seems to be fine for me, on two different systems (one
Linux, on Mac OS X).

> Also, the comment could be a bit more explicit on the meaning of the return
> value. I personally find returning true on error counter-intuitive.

I, too, find it counter-intuitive... but it seems to be the way things
are done, so I've gotten used to it. I've improved the comment a bit.

>>
>> +    if (ICS) {
>> +      // C++ [over.ics.ref]p1:
>> +      //   When a parameter of reference type binds directly (8.5.3)
>> +      //   to an argument expression, the implicit conversion sequence
>> +      //   is the identity conversion, unless the argument expression
>> +      //   has a type that is a derived class of the parameter type,
>> +      //   in which case the implicit conversion sequence is a
>> +      //   derived-to-base Conversion (13.3.3.1).
>> +      ICS->ConversionKind =
>> ImplicitConversionSequence::StandardConversion;
>> +      ICS->Standard.First = ICK_Identity;
>> +      ICS->Standard.Second = DerivedToBase? ICK_Derived_To_Base :
>> ICK_Identity;
>> +      ICS->Standard.Third = ICK_Identity;
>> +      ICS->Standard.FromTypePtr = T2.getAsOpaquePtr();
>> +      ICS->Standard.ToTypePtr = T1.getAsOpaquePtr();
>> +      ICS->ReferenceBinding = true;
>> +      ICS->DirectBinding = true;
>>
>
> What about qualification? Isn't this recorded in the sequence? I would have
> thought that a function can be overloaded on T& vs const T&, so whether the
> argument is const or non-const would be needed for resolution.
> Or am I overlooking something terribly obvious?

There's nothing terribly obvious in this part of the standard :)

So, qualification isn't actually recorded in the sequence, because the
reference binding subsumes qualification (meaning: there is no
qualification conversion in that implicit conversion sequence).
Instead, qualifiers are handled while ranking implicit conversion
sequences ([over.ics.rank]p3b1, 4th sub-bullet). My later commit [*]
added support for these ranking rules, so that T& vs. const T&
overloading behaves as expected.

  - Doug

[*] http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081027/008692.html