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
