[cfe-commits] [PATCH] Add smarter sorting of overload candidates that failed template deduction

Kaelyn Uhrain rikka at google.com
Fri Sep 9 12:26:51 PDT 2011


On Fri, Sep 9, 2011 at 11:01 AM, Chandler Carruth <chandlerc at google.com>wrote:

> I hate to pull out the bikeshed paint... But why not!
>
>
> On Fri, Sep 9, 2011 at 10:56 AM, Kaelyn Uhrain <rikka at google.com> wrote:
>
>> I moved TDK_InvalidExplicitArguments to rank 5 and made TDK_Too*Arguments
>> rank 6 since I feel it's slightly more likely that someone gave the wrong
>> argument to a template than to have the wrong number of arguments (with
>> candidates needing the wrong number of arguments being a more common case,
>> especially candidates that are way way out in left field).
>
>
> I'm not sure actually. I often leave one argument off the end of a
> function. I don't think that's too unlikely.
>
> Ah, I think I know what I really want here.
>
> If the arguments that are specified match the parameters, but there simply
> aren't enough or is one too many, I would rank that candidate before an
> explicit argument mismatch.
>
> If the arguments don't match the parameter types *and* there are too many
> or not enough, I would rank that candidate after.
>
> Is that feasible to implement?
>

The catch is that there is only a single reason given for failure... I
haven't looked at the overloaded-template deduction code so I'm not sure if,
in the case that an explicit argument doesn't match the parameter type *and*
the wrong number of args are given whether the result is
TDK_InvalidExplicitArguments or TDK_TooManyArguments/TDK_TooFewArguments.
Your proposal would require adding an additional TemplateDeductionResult
value that indicates both invalid explicit arguments and the wrong number of
arguments, plus possibly nontrivial changes for the deduction code to detect
both and record it instead of (possibly) stopping checking once one or the
other is true.

One reason I chose to rank TDK_InvalidExplicitArguments above
TDK_Too*Arguments is the theory that there are likely more failed candidates
with the wrong number of arguments than failed candidates because of an
invalid explicit argument. Currently the more general comparison
function/struct (CompareOverloadCandidatesForDisplay) it always sorts arity
mismatches (in non-template-deduction-failure cases) after all other
candidates, and if nothing else sorting TDK_InvalidExplicitArguments before
TDK_Too*Arguments provides consistency with
CompareOverloadCandidatesForDisplay within the scope of template deduction
failures.

And for what it's worth, I think adding new values to
TemplateDeductionResult to be able to do things like sort some arity
mismatches before other template deduction types with other arity mismatches
after those types to be better suited for a separate patch as it involves
more changes to the actual overload resolution and/or template deduction
code. This patch is just about making the comparison function used to sort
the candidates for display a bit smarter based on already available
information.

Cheers,
Kaelyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110909/232a7ef8/attachment.html>


More information about the cfe-commits mailing list