[PATCH] Use the correct from type in a SCS

[Ehsan Akhgari]

Any advice on how to proceed here?

Thanks!

--
Ehsan
<http://ehsanakhgari.org/>


On Mon, Jul 14, 2014 at 10:57 PM, Ehsan Akhgari <ehsan.akhgari at gmail.com>
wrote:

> 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/20140721/3966e500/attachment.html>