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++/114456] [C++26] P0609R3 - Attributes for structured bindings Date: Tue, 30 Apr 2024 06:58:00 +0000 [thread overview] Message-ID: <bug-114456-4-ZXzoUKRN6V@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114456-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456 --- Comment #4 from GCC 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:bd35a92f8d44e91c96e8b6f01805fe4a68acf9eb commit r15-61-gbd35a92f8d44e91c96e8b6f01805fe4a68acf9eb Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Apr 30 08:57:15 2024 +0200 c++: Implement C++26 P0609R3 - Attributes for Structured Bindings [PR114456] The following patch implements the P0609R3 paper; we build the VAR_DECLs for the structured binding identifiers early, so all we need IMHO is just to parse the attributed identifier list and pass the attributes to the VAR_DECL creation. The paper mentions maybe_unused and gnu::nonstring attributes as examples where they can be useful. Not sure about either of them. For maybe_unused, the thing is that both GCC and clang already don't diagnose maybe unused for the structured binding identifiers, because it would be a false positive too often; and there is no easy way to find out if a structured binding has been written with the P0609R3 paper in mind or not (maybe we could turn it on if in the structured binding is any attribute, even if just [[]] and record that as a flag on the whole underlying decl, so that we'd diagnose auto [a, b, c[[]]] = d; // use a, c but not b but not auto [e, f, g] = d; // use a, c but not b ). For gnu::nonstring, the issue is that we currently don't allow the attribute on references to char * or references to char[], just on char */char[]. I've filed a PR for that. The first testcase in the patch tests it on [[]] and [[maybe_unused]], just whether it is parsed properly, second on gnu::deprecated, which works. Haven't used deprecated attribute because the paper said that attribute is for further investigation. 2024-04-30 Jakub Jelinek <jakub@redhat.com> PR c++/114456 gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_structured_bindings for C++26 to 202403L rather than 201606L. gcc/cp/ * parser.cc (cp_parser_decomposition_declaration): Implement C++26 P0609R3 - Attributes for Structured Bindings. Parse attributed identifier lists for structured binding declarations, pass the attributes to start_decl. gcc/testsuite/ * g++.dg/cpp26/decomp1.C: New test. * g++.dg/cpp26/decomp2.C: New test. * g++.dg/cpp26/feat-cxx26.C (__cpp_structured_bindings): Expect 202403 rather than 201606.
next prev parent reply other threads:[~2024-04-30 6:58 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-25 11:08 [Bug c++/114456] New: " jakub at gcc dot gnu.org 2024-03-25 17:21 ` [Bug c++/114456] " jakub at gcc dot gnu.org 2024-03-25 17:53 ` pinskia at gcc dot gnu.org 2024-04-26 12:41 ` jakub at gcc dot gnu.org 2024-04-30 6:58 ` cvs-commit at gcc dot gnu.org [this message] 2024-04-30 7:08 ` 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-114456-4-ZXzoUKRN6V@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: 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).