public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/105766] requires std::is_constructible<> reports 'constraint depends on itself' error.
Date: Tue, 19 Jul 2022 18:05:16 +0000	[thread overview]
Message-ID: <bug-105766-4-Fq3FakiePI@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105766-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105766

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:68f37670eff0b872ce5dfd382c8d8f3206bdfc27

commit r13-1755-g68f37670eff0b872ce5dfd382c8d8f3206bdfc27
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Jul 19 14:04:13 2022 -0400

    c++: shortcut bad reference binding [PR94894]

    In case of l/rvalue or cv-qual mismatch during reference binding, we
    try to give more helpful diagnostics by computing a bad conversion that
    allows the mismatch.  But in doing so, we may end up considering and
    instantiating a conversion function that could induce a hard error and
    in turn cause us to reject otherwise valid code.  We could just give up
    on producing a better diagnostic here, but ideally we'd preserve the
    better diagnostics for invalid code while avoiding unnecessary template
    instantiations for valid code.

    To that end, this patch adapts the bad conversion shortcutting mechanism
    from r12-3346-g47543e5f9d1fc5 to additionally handle this situation.
    The main observation from there is that during overload resolution, if we
    know we have a strictly viable candidate then we don't need to distinguish
    between an unviable and non-strictly viable candidate.  Thus we don't
    need to distinguish between an invalid and bad conversion either, which
    is what this patch exploits.  Of course, we don't know whether we have a
    strictly viable candidate until after the fact, so we still need to
    remember when we deferred distinguishing between an invalid and bad
    conversion.  This patch adds a special conversion kind ck_deferred_bad
    for this purpose.

            PR c++/94894
            PR c++/105766
            PR c++/106201

    gcc/cp/ChangeLog:

            * call.cc (enum conversion_kind): Add ck_deferred_bad enumerator.
            (has_next): Return false for it.
            (reference_binding): Return a ck_deferred_bad conversion instead
            of an actual bad conversion when LOOKUP_SHORTCUT_BAD_CONVS is set.
            Remove now obsolete early exit for the incomplete TO case.
            (implicit_conversion_1): Don't mask out LOOKUP_SHORTCUT_BAD_CONVS.
            (add_function_candidate): Set LOOKUP_SHORTCUT_BAD_CONVS iff
            shortcut_bad_convs.
            (missing_conversion_p): Also return true for a ck_deferred_bad
            conversion.
            * cp-tree.h (LOOKUP_SHORTCUT_BAD_CONVS): Define.

    gcc/testsuite/ChangeLog:

            * g++.dg/conversion/ref8.C: New test.
            * g++.dg/conversion/ref9.C: New test.

  reply	other threads:[~2022-07-19 18:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-29 10:40 [Bug c++/105766] New: " stream009 at gmail dot com
2022-07-19 18:05 ` cvs-commit at gcc dot gnu.org [this message]
2022-08-01 14:36 ` [Bug c++/105766] " ppalka at gcc dot gnu.org
2024-03-08 21:47 ` ppalka at gcc dot gnu.org

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=bug-105766-4-Fq3FakiePI@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).