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 libstdc++/100577] [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object
Date: Thu, 03 Jun 2021 13:50:36 +0000	[thread overview]
Message-ID: <bug-100577-4-CyCUrIiVo9@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-100577-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 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:57ed620ebfa4275d04efeec973e88f506b0e3ba8

commit r12-1184-g57ed620ebfa4275d04efeec973e88f506b0e3ba8
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Jun 3 09:49:30 2021 -0400

    libstdc++: Simplify range adaptors' forwarding of bound args [PR100577]

    r11-8053 rewrote the range adaptor implementation in conformance with
    P2281R1, making partial application act like a SFINAE-friendly perfect
    forwarding call wrapper.  Making SFINAE-friendliness coexist with
    perfect forwarding here requires adding fallback deleted operator()
    overloads (as described in e.g. section 5.5 of P0847R6).  But
    unfortunately, as reported in PR100577, this necessary technique of
    using of deleted overloads regresses diagnostics for ill-formed calls to
    partially applied range adaptors in GCC.

    Although GCC's diagnostics can arguably be improved here by having the
    compiler explain why the other candidates weren't viable when overload
    resolution selects a deleted candidate, we can also largely work around
    this on the library side (and achieve more concise diagnostics than by
    a frontend-side improvement alone) if we take advantage of the
    observation that not all range adaptors need perfect forwarding call
    wrapper semantics, in fact only views::split currently needs it, because
    all other range adaptors either take no extra arguments or only
    arguments that are expected to be freely/cheaply copyable, e.g. function
    objects and integer-like types.  (The discussion section in P2281R1 goes
    into detail about why views::split is special.)

    To that end, this introduces opt-in flags for denoting a range adaptor
    as having "simple" extra arguments (in the case of a range adaptor
    non-closure) or having a "simple" call operator (in the case of a range
    adaptor closure).  These flags are then used to conditionally simplify
    the operator() for the generic _Partial and _Pipe class templates, down
    from needing three overloads thereof (including one defined as deleted)
    to just needing a single overload.  The end result is that diagnostic
    quality is restored for all adaptors except for views::split, and
    diagnostics for the adaptors are generally made more concise since
    there's only a single _Partial/_Pipe overload to diagnose instead of
    three of them.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100577
            * include/std/ranges (_RangeAdaptorClosure): Document
            _S_has_simple_call_op mechanism.
            (_RangeAdaptor): Document _S_has_simple_extra_args mechanism.
            (__closure_has_simple_call_op): New concept.
            (__adaptor_has_simple_extra_args): Likewise.
            (_Partial<_Adaptor, _Args...>): New partial specialization.
            (_Partial<_Adaptor, _Arg>): Likewise.
            (_Pipe<_Lhs, _Rhs>): Likewise.
            (views::_All::_S_has_simple_call_op): Define to true.
            (views::_Filter::_S_has_simple_extra_args): Likewise.
            (views::_Transform::_S_has_simple_extra_args): Likewise.
            (views::_Take::_S_has_simple_extra_args): Likewise.
            (views::_TakeWhile::_S_has_simple_extra_args): Likewise.
            (views::_Drop::_S_has_simple_extra_args): Likewise.
            (views::_DropWhile::_S_has_simple_extra_args): Likewise.
            (views::_Join::_S_has_simple_call_op): Likewise.
            (views::_Split): Document why we don't define
            _S_has_simple_extra_args to true for this adaptor.
            (views::_Common::_S_has_simple_call_op): Define to true.
            (views::_Reverse::_S_has_simple_call_op): Likewise.
            (views::_Elements::_S_has_simple_call_op): Likewise.
            * testsuite/std/ranges/adaptors/100577.cc: New test.

  parent reply	other threads:[~2021-06-03 13:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13  2:16 [Bug libstdc++/100577] New: " ppalka at gcc dot gnu.org
2021-05-13  2:19 ` [Bug libstdc++/100577] " ppalka at gcc dot gnu.org
2021-05-13  3:04 ` ppalka at gcc dot gnu.org
2021-05-13  3:12 ` ppalka at gcc dot gnu.org
2021-06-03 13:50 ` cvs-commit at gcc dot gnu.org [this message]
2021-06-10 21:29 ` cvs-commit at gcc dot gnu.org
2021-06-10 21:39 ` 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-100577-4-CyCUrIiVo9@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).