[PATCH] Use the correct from type in a SCS

[Ehsan Akhgari]

On Mon, Jul 14, 2014 at 10:39 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Mon, Jul 14, 2014 at 5:15 AM, Ehsan Akhgari <ehsan.akhgari at gmail.com>
> wrote:
>
>> On Sun, Jul 13, 2014 at 9:04 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>
>>> The problem in PR20218 is visible in its notes:
>>>
>>> test.cpp(4,3) :  note: candidate constructor [with X = int, Y = void ()]
>>>   pair(X&&, Y&&);
>>>   ^
>>>
>>> This deduction is wrong. We should get Y = void (&)(). Presumably the
>>> 'deduce an lvalue reference if an rvalue reference to T binds to an lvalue'
>>> rule isn't being applied appropriately in the case where the lvalue is an
>>> overload set.
>>>
>>
>> Thanks, Richard!  Given the above, and also r212916, do we want to still
>> take my patch here?
>>
>
> Does it change the diagnostic in this case (from 'no overload [...]' to
> 'no known conversion from 'void ()' to 'int'):
>
> template<typename T> void f();
> int g(int);
> int k = g(f<int>);
>
> If so, please go ahead with that as a testcase.
>

No, both before and after, I get:

$ ./bin/clang-cl -c test.cpp
test.cpp(3,9) :  error: no matching function for call to 'g'
int k = g(f<int>);
        ^
test.cpp(2,5) :  note: candidate function not viable: no overload of 'f'
matching 'int' for 1st argument
int g(int);
    ^
1 error generated.


>
> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>>
>>
>>
>>>
>>> On Tue, Jul 8, 2014 at 3:13 PM, Ehsan Akhgari <ehsan.akhgari at gmail.com>
>>> wrote:
>>>
>>>> On Tue, Jul 8, 2014 at 6:05 PM, Richard Smith <richard at metafoo.co.uk>
>>>> wrote:
>>>>
>>>>> On Sun, Jul 6, 2014 at 12:16 PM, Ehsan Akhgari <
>>>>> ehsan.akhgari at gmail.com> wrote:
>>>>>
>>>>>> Hi doug.gregor,
>>>>>>
>>>>>> If during constructing a standard conversion sequence, we resolve an
>>>>>> overload, we need to adjust the from type in the SCS according to the
>>>>>> resolved operator.
>>>>>>
>>>>>> I found this bug when debugging PR20218.  It doesn't completely fix
>>>>>> that
>>>>>> test case though.
>>>>>>
>>>>>
>>>>> The fix looks correct, but please provide some kind of test case for
>>>>> this patch (even if it doesn't solve PR20218's test case).
>>>>>
>>>>
>>>> I tried to do that, but I wasn't able to write a simpler test case
>>>> similar to that of PR20218 which would have an observable outcome different
>>>> after this patch...  Any ideas how I can write a good test case for this?
>>>>
>>>> Thanks!
>>>> --
>>>> Ehsan
>>>> <http://ehsanakhgari.org/>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>  http://reviews.llvm.org/D4402
>>>>>>
>>>>>> Files:
>>>>>>   lib/Sema/SemaOverload.cpp
>>>>>>
>>>>>> Index: lib/Sema/SemaOverload.cpp
>>>>>> ===================================================================
>>>>>> --- lib/Sema/SemaOverload.cpp
>>>>>> +++ lib/Sema/SemaOverload.cpp
>>>>>> @@ -1462,6 +1462,7 @@
>>>>>>        // We were able to resolve the address of the overloaded
>>>>>> function,
>>>>>>        // so we can convert to the type of that function.
>>>>>>        FromType = Fn->getType();
>>>>>> +      SCS.setFromType(FromType);
>>>>>>
>>>>>>        // we can sometimes resolve &foo<int> regardless of ToType, so
>>>>>> check
>>>>>>        // if the type matches (identity) or we are converting to bool
>>>>>>
>>>>>> _______________________________________________
>>>>>> cfe-commits mailing list
>>>>>> cfe-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140714/43eba818/attachment.html>