Re: [PATCH,c++] describe reasons for function template overload resolution failure

[Jason Merrill <jason@redhat.com>]

On 05/18/2011 03:00 PM, Nathan Froyd wrote:
> Thank you for the review.  I'll go back and try things the way you suggest;
> before I go off and do that, I've taken your comments to mean that:
>
> - fn_type_unification/type_unification_real and associated callers should take
>    a boolean `explain' parameter, which is normally false;
>
> - failed calls to fn_type_unification should save the arguments for the call
>    for future explanation;
>
> - printing diagnostic messages should call fn_type_unification with the saved
>    arguments and a true `explain' parameter.

Yes, that's what I had in mind.  Though I think you can reconstruct the 
arguments rather than save them.

...
> bar.hh:4095:63 note: bar (...)
> bar.hh:....... error: [some message from tf_warning_or_error code]

> I'm not sure that the last location there will necessary be the same as the
> one that's printed for the declaration.  I think I'll punt on that issue for
> the time being until we see how the diagnostics work out.  There's also the
> matter of the error vs. note diagnostic.  I think it'd be nicer to keep the
> conformity of a note for all the explanations

Nicer, yes, but I think that's a secondary concern after usefulness of 
the actual message.  In similar cases I've introduced the errors with 
another message like "%qD is implicitly deleted because the default 
definition would be ill-formed:"

Or, in this case, "deduction failed because substituting the template 
arguments would be ill-formed:"

>; the only way I see to do that
> is something like:
>
> - Add a tf_note flag; pass it at all appropriate call sites when explaining
>    things;
>
> - Add a tf_issue_diagnostic flag that's the union of tf_{warning,error,note};
>
> - Change code that looks like:
>
>    if (complain&  tf_warning_or_error)
>      error (<STUFF>);
>
>    to something like:
>
>    if (complain&  tf_issue_diagnostic)
>      emit_diagnostic (complain&  tf_note ? DK_NOTE : DK_ERROR,<STUFF>);
>
>    passing input_location if we're not already passing a location.
>
> That involves a lot of code churn.  (Not a lot if you just modified the
> functions above, but with this scheme, you'd have to call instantiate_template
> again from the diagnostic code, and I assume you'd want to call that with
> tf_note as well, which means hitting a lot more code.)  I don't see a better
> way to keep the diagnostics uniform, but I might be making things too
> complicated; did you have a different idea of how to implement what you were
> suggesting?

That all makes sense, but I'd put it in a follow-on patch.  And wrap the 
complexity in a cp_error function that takes a complain parameter and 
either gives no message, a note, or an error depending.

Jason