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++/102611] [C++23] P2128R6 - Multidimensional subscript operator
Date: Thu, 25 Nov 2021 07:38:23 +0000	[thread overview]
Message-ID: <bug-102611-4-6h8qAE2lma@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102611-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b38c9cf6d570f6c4c1109e00c8b81d82d0f24df3

commit r12-5510-gb38c9cf6d570f6c4c1109e00c8b81d82d0f24df3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Nov 25 08:36:20 2021 +0100

    c++: Implement C++23 P2128R6 - Multidimensional subscript operator
[PR102611]

    The following patch implements the C++23 Multidimensional subscript
operator
    P2128R6 paper.
    As C++20 and older only allow a single expression in between []s (albeit
    for C++20 with a deprecation warning if it is a comma expression) and even
    in C++23 and for the coming years I think the vast majority of subscript
    expressions will still have a single expression and even in C++23 it is
    quite special, as e.g. the builtin operator requires exactly one
    assignment expression, the patch attempts to optimize for that case and
    if possible not to slow down that common case (or use more memory for it).
    So, already during parsing it differentiates between that (uses a single
    index_exp tree in that case) and the new cases (zero or two+ expressions
    in the list), for which it sets index_exp to NULL_TREE and uses a
    releasing_vec instead similarly to how e.g. finish_call_expr uses it.
    In call.c it introduces new functions build_op_subscript{,_1} which are
    something in between build_new_op{,_1} and build_op_call{,_1}.
    The former requires fixed number of arguments (and the patch still uses
    it for the common case of subscript with exactly one index expression),
    the latter handles variable number of arguments but is too CALL_EXPR
specific
    and handles various cases that are unnecessary for the subscript.
    Right now the subscript for 0 or 2+ expressions doesn't need to deal with
    builtin candidates and so is quite simple.

    As discussed in the paper, for backwards compatibility, if for 2+ index
    expressions build_op_subscript fails (called with tf_none) and the
    expressions together form a valid comma expression (again checked with
    tf_none), it is used that C++20-ish way with a pedwarn about it, but if
    even that fails, build_op_subscript is called again with standard complain
    flags to diagnose it in the new way.  And similarly for the builtin case.

    The -Wcomma-subscript warning used to be enabled by default unless
    -Wno-deprecated.  Since the C/C++98..20 behavior is no longer deprecated,
    but ill-formed or changed meaning, it is now for C++23 enabled by
    default regardless of -Wno-deprecated and controls the pedwarn (but not the
    errors emitted if something wasn't valid before and isn't valid in C++23
    either).

    2021-11-25  Jakub Jelinek  <jakub@redhat.com>

            PR c++/102611
    gcc/
            * doc/invoke.texi (-Wcomma-subscript): Document that for
            -std=c++20 the option isn't enabled by default with -Wno-deprecated
            but for -std=c++23 it is.
    gcc/c-family/
            * c-opts.c (c_common_post_options): Enable -Wcomma-subscript by
            default for C++23 regardless of warn_deprecated.
            * c-cppbuiltin.c (c_cpp_builtins): Predefine
            __cpp_multidimensional_subscript=202110L for C++23.
    gcc/cp/
            * cp-tree.h (build_op_subscript): Implement P2128R6
            - Multidimensional subscript operator.  Declare.
            (class releasing_vec): Add release method.
            (grok_array_decl): Remove bool argument, add vec<tree, va_gc> **
            and tsubst_flags_t arguments.
            (build_min_non_dep_op_overload): Declare another overload.
            * parser.c (cp_parser_parenthesized_expression_list_elt): New
function.
            (cp_parser_postfix_open_square_expression): Mention C++23 syntax in
            function comment.  For C++23 parse zero or more than one
initializer
            clauses in expression list, adjust grok_array_decl caller.
            (cp_parser_parenthesized_expression_list): Use
            cp_parser_parenthesized_expression_list_elt.
            (cp_parser_builtin_offsetof): Adjust grok_array_decl caller.
            * decl.c (grok_op_properties): For C++23 don't check number
            of arguments of operator[].
            * decl2.c (grok_array_decl): Remove decltype_p argument, add
            index_exp_list and complain arguments.  If index_exp is NULL,
            handle *index_exp_list as the subscript expression list.
            * tree.c (build_min_non_dep_op_overload): New overload.
            * call.c (add_operator_candidates, build_over_call): Adjust
comments
            for removal of build_new_op_1.
            (build_op_subscript): New function.
            * pt.c (tsubst_copy_and_build_call_args): New function.
            (tsubst_copy_and_build) <case ARRAY_REF>: If second
            operand is magic CALL_EXPR with ovl_op_identifier (ARRAY_REF)
            as CALL_EXPR_FN, tsubst CALL_EXPR arguments including expanding
            pack expressions in it and call grok_array_decl instead of
            build_x_array_ref.
            <case CALL_EXPR>: Use tsubst_copy_and_build_call_args.
            * semantics.c (handle_omp_array_sections_1): Adjust grok_array_decl
            caller.
    gcc/testsuite/
            * g++.dg/cpp2a/comma1.C: Expect different diagnostics for C++23.
            * g++.dg/cpp2a/comma3.C: Likewise.
            * g++.dg/cpp2a/comma4.C: Expect diagnostics for C++23.
            * g++.dg/cpp2a/comma5.C: Expect different diagnostics for C++23.
            * g++.dg/cpp23/feat-cxx2b.C: Test __cpp_multidimensional_subscript
            predefined macro.
            * g++.dg/cpp23/subscript1.C: New test.
            * g++.dg/cpp23/subscript2.C: New test.
            * g++.dg/cpp23/subscript3.C: New test.
            * g++.dg/cpp23/subscript4.C: New test.
            * g++.dg/cpp23/subscript5.C: New test.
            * g++.dg/cpp23/subscript6.C: New test.

  parent reply	other threads:[~2021-11-25  7:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 16:18 [Bug c++/102611] New: " mpolacek at gcc dot gnu.org
2021-10-06 13:13 ` [Bug c++/102611] " jakub at gcc dot gnu.org
2021-10-13 14:42 ` jakub at gcc dot gnu.org
2021-10-13 18:24 ` jakub at gcc dot gnu.org
2021-11-25  7:38 ` cvs-commit at gcc dot gnu.org [this message]
2021-11-25  7:42 ` jakub 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-102611-4-6h8qAE2lma@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).