public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jason Merrill <jason@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r11-5865] c++: Distinguish ambiguity from no valid candidate Date: Tue, 8 Dec 2020 20:13:08 +0000 (GMT) [thread overview] Message-ID: <20201208201308.EC7143850426@sourceware.org> (raw) https://gcc.gnu.org/g:a988a398d6daef3072cd2d07a21980911d8f93fc commit r11-5865-ga988a398d6daef3072cd2d07a21980911d8f93fc Author: Jason Merrill <jason@redhat.com> Date: Mon Dec 7 17:21:47 2020 -0500 c++: Distinguish ambiguity from no valid candidate Several recent C++ features are specified to try overload resolution, and if no viable candidate is found, do something else. But our error return doesn't distinguish between that situation and finding multiple viable candidates that end up being ambiguous. We're already trying to separately return the single function we found even if it ends up being ill-formed for some reason; for ambiguity let's pass back error_mark_node, to be distinguished from NULL_TREE meaning no viable candidate. gcc/cp/ChangeLog: * call.c (build_new_op_1): Set *overload for ambiguity. (build_new_method_call_1): Likewise. Diff: --- gcc/cp/call.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gcc/cp/call.c b/gcc/cp/call.c index f1e0bcb796b..221e3de0c70 100644 --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -6357,6 +6357,8 @@ build_new_op_1 (const op_location_t &loc, enum tree_code code, int flags, print_z_candidates (loc, candidates); } result = error_mark_node; + if (overload) + *overload = error_mark_node; } else if (TREE_CODE (cand->fn) == FUNCTION_DECL) { @@ -10438,6 +10440,8 @@ build_new_method_call_1 (tree instance, tree fns, vec<tree, va_gc> **args, free (pretty_name); } call = error_mark_node; + if (fn_p) + *fn_p = error_mark_node; } else {
reply other threads:[~2020-12-08 20:13 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201208201308.EC7143850426@sourceware.org \ --to=jason@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).