[PATCH] Use the correct from type in a SCS

[Richard Smith]

On Mon, Jul 21, 2014 at 3:25 PM, Ehsan Akhgari <ehsan.akhgari at gmail.com>
wrote:

> Any advice on how to proceed here?
>

It seems this is genuinely not observable, but makes SCS a little bit more
technically correct. I'm happy for you to commit this as a "refactoring".
Or to just drop this patch. Your choice. :)

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/a89e835f/attachment.html>