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

Richard Smith richard at metafoo.co.uk
Tue May 6 15:43:14 PDT 2014


On Tue, May 6, 2014 at 3:13 PM, Kaelyn Takata <rikka at google.com> wrote:

> 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.
>

Function will be null when we have a surrogate call candidate for an object
with a conversion to a function pointer type. So we'd hit the
not-a-strict-weak-order case for code like:

template<typename T> using id = T;
struct A {
  operator id<void (*)(int)>();
  operator id<void (*)(float)>();
} a;
int main() { a(); }


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


More information about the cfe-commits mailing list