r208062 - Fix crash when one overload candidate is a template instead of a function. Patch by Kaelyn Takata.

[Kaelyn Takata]

On Tue, May 6, 2014 at 2:00 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Tue, May 6, 2014 at 12:16 PM, Kaelyn Takata <rikka at google.com> wrote:
>
>> On Tue, May 6, 2014 at 12:02 AM, Richard Smith <richard at metafoo.co.uk>wrote:
>>
>>> On Mon, May 5, 2014 at 11:35 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
>>>
>>>> Author: nicholas
>>>> Date: Tue May  6 01:35:27 2014
>>>> New Revision: 208062
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=208062&view=rev
>>>> Log:
>>>> Fix crash when one overload candidate is a template instead of a
>>>> function. Patch by Kaelyn Takata.
>>>>
>>>> Testcase coming out of creduce will land in a separate commit shortly.
>>>>
>>>> Also, it appears that this callback is used even in a SFINAE context
>>>> where the results are never displayed.
>>>>
>>>> Modified:
>>>>     cfe/trunk/lib/Sema/SemaOverload.cpp
>>>>
>>>> Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
>>>> URL:
>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=208062&r1=208061&r2=208062&view=diff
>>>>
>>>> ==============================================================================
>>>> --- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
>>>> +++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue May  6 01:35:27 2014
>>>> @@ -9260,6 +9260,7 @@ struct CompareOverloadCandidatesForDispl
>>>>            L->FailureKind == ovl_fail_too_few_arguments) {
>>>>          if (R->FailureKind == ovl_fail_too_many_arguments ||
>>>>              R->FailureKind == ovl_fail_too_few_arguments) {
>>>> +          if (!L->Function || !R->Function) return !R->Function;
>>>>
>>>
>>> What happens if !L->Function && !R->Function? Is this a strict weak
>>> order?
>>>
>>
>> If  !L->Function && !R->Function then L will be ordered before R. This
>> isn't a strict weak order in that if you transpose L and R then the
>> original R would be ordered before the original L, but that was true prior
>> to my adding the parameter-count based sorting (when false was always
>> returned for L if it had too few or too many arguments, regardless of what
>> R was).
>>
>
> If this isn't a strict weak ordering, we have a bug: we're passing this as
> the comparator to std::sort.
>

The only other option I can think of for here would be to return
L->Function != nullptr, so that L is ordered before R only if L->Function
is not NULL (which would be a closer parallel to the old behavior of always
returning false if L->FailureKind was an arity mismatch, regardless of what
R was). I don't really know/understand under what circumstances (for either
L or R) that Function can be NULL and the FailureKind be an arity mismatch,
so I don't have any idea what the proper ordering could or should be.


>             int LDist = std::abs((int)L->Function->getNumParams() -
>>>> (int)NumArgs);
>>>>            int RDist = std::abs((int)R->Function->getNumParams() -
>>>> (int)NumArgs);
>>>>            if (LDist == RDist)
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-commits mailing list
>>>> cfe-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20140506/da2f60b8/attachment.html>