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: link
Be 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).