See <https://wg21.link/P2552R3>.
Created attachment 55791 [details] gcc14-pr110345-wip.patch So, parts of this paper has been already fixed in r13-3848-g05119c345797bc04c . The fallthrough stuff is still outstanding I think and I'll have a look. The largest nightmare is diagnostics on standard attributes which appertain to something that shouldn't allow them, I'm lost there. I went through the grammar (except for modules) and tried to find all spots where standard allows attribute-specifier-seq and tried to write that into a testcase in the attached patch, for now for deprecated attribute and marked all -pedantic-errors diagnostics. I've added lots of FIXMEs in there where I don't really know. There are even 4 spots where we don't parse the attributes at all (and clang++ does), on the other side there are 4 spots where we do parse them and clang++ doesn't. I think to mark this paper fully resolved we'd need to resolve the FIXMEs and copy/adjust the test for all other standard attributes and verify we emit at least some diagnostics with -pedantic-errors where the standard attributes aren't allowed to appertain to.
The fallthrough stuff is still outstanding I think and I'll have a look. part is done in r14-5561-g52eedfa00960f2d255ec542626e3531a65aa8bb8 The rest unresolved.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:2f90f3850eaf9d703d9eb63d5f0347158aa11027 commit r15-2948-g2f90f3850eaf9d703d9eb63d5f0347158aa11027 Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Aug 16 11:43:18 2024 +0200 c++: Pedwarn on [[]]; at class scope [PR110345] For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. The fourth issue is that we just emit (when enabled) -Wextra-semi warning not just for lone semicolon at class scope (correct), but also for [[]]; or [[whatever]]; there too. While just semicolon is valid in C++11 and newer, https://eel.is/c++draft/class.mem#nt:member-declaration allows empty-declaration, unlike namespace scope or block scope something like attribute-declaration or empty statement with attributes applied for it aren't supported. While syntactically it matches attribute-specifier-seq [opt] decl-specifier-seq [opt] member-declarator-list [opt] ; with the latter two omitted, there is https://eel.is/c++draft/class.mem#general-3 which says that is not valid. So, the following patch emits a pedwarn in that case. 2024-08-16 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * parser.cc (cp_parser_member_declaration): Call maybe_warn_extra_semi only if it is empty-declaration, if there are some tokens like attribute, pedwarn that the declaration doesn't declare anything. * g++.dg/cpp0x/gen-attrs-84.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:1db5ca04da365ac57f7d788a85055edcf13da708 commit r15-3045-g1db5ca04da365ac57f7d788a85055edcf13da708 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Aug 20 22:15:03 2024 +0200 c++: Parse and ignore attributes on base specifiers [PR110345] For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. This is the third issue I found. https://eel.is/c++draft/class.derived#general-1 has attribute-specifier-seq at the start of base-specifier. The following patch parses it there and warns about those. 2024-08-20 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * parser.cc (cp_parser_base_specifier): Parse standard attributes at the start and emit a warning if there are any non-ignored ones. * g++.dg/cpp0x/gen-attrs-83.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:d05949558ef1c8eeeb07399174a64f968f70e3ee commit r15-3046-gd05949558ef1c8eeeb07399174a64f968f70e3ee Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Aug 20 22:17:41 2024 +0200 c++: Appertain standard attributes after array closing square bracket to array type rather than declarator [PR110345] For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. This is the second issue I found. The comment already correctly says that attributes after closing ] appertain to the array type, but we were appending them to returned_attrs, so effectively applying them to the declarator (as if they appeared right after declarator-id). 2024-08-20 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * decl.cc (grokdeclarator): Apply declarator->std_attributes for cdk_array to type, rather than chaining it to returned_attrs. * g++.dg/cpp0x/gen-attrs-82.C: New test. * g++.dg/gomp/attrs-3.C (foo): Expect different diagnostics for omp::directive attribute after closing square bracket of an automatic declaration and add a test with the attribute after array's declarator-id.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:b748e2eed0df9e691a530a0b8faea9f673bdf2b5 commit r15-3315-gb748e2eed0df9e691a530a0b8faea9f673bdf2b5 Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Aug 30 09:40:34 2024 +0200 c++: Allow standard attributes after closing square bracket in new-type-id [PR110345] For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. The first thing I found is that we aren't parsing standard attributes in noptr-new-declarator - https://eel.is/c++draft/expr.new#1 The following patch parses it there, for the non-outermost arrays applies normally the attributes to the array type, for the outermost where we just set *nelts and don't really build an array type just warns that we ignore those attributes (or, do you think we should just build an array type in that case and just take its element type?). 2024-08-30 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * parser.cc (make_array_declarator): Add STD_ATTRS argument, set declarator->std_attributes to it. (cp_parser_new_type_id): Warn on non-ignored std_attributes on the array declarator which is being omitted. (cp_parser_direct_new_declarator): Parse standard attributes after closing square bracket, pass it to make_array_declarator. (cp_parser_direct_declarator): Pass std_attrs to make_array_declarator instead of setting declarator->std_attributes manually. * g++.dg/cpp0x/gen-attrs-80.C: New test. * g++.dg/cpp0x/gen-attrs-81.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:49b142f2ef5d985dd6c4509d692ee4dfedfd4658 commit r15-6328-g49b142f2ef5d985dd6c4509d692ee4dfedfd4658 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 18 11:52:31 2024 +0100 c++: Handle enum attributes like class attributes [PR110345] As the following testcase shows, cp_parser_decl_specifier_seq was calling warn_misplaced_attr_for_class_type only for class types and not for enum types, while check_tag_decl calls them for both class and enum types. Enum types are really the same case here, the attribute needs to go before the type name to apply to all instances of the type. Additionally, when warn_misplaced_attr_for_class_type is called, it diagnoses something and so it is fine to drop the attributes then on the floor, but in case it wasn't a type decision, it silently discarded the attributes, which is invalid for the ignorability of standard attributes paper. This patch in that case adds them to decl_specs->std_attributes and let it be diagnosed later (e.g. in grokdeclarator). 2024-12-18 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * parser.cc (cp_parser_decl_specifier_seq): Call warn_misplaced_attr_for_class_type for all OVERLOAD_TYPE_P types, not just CLASS_TYPE_P. When not calling warn_misplaced_attr_for_class_type, don't clear attrs and add it to decl_specs->std_attributes instead. * g++.dg/cpp0x/gen-attrs-85.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:d003a3862aeac72d0417cc41daafdf968bdb1839 commit r15-6329-gd003a3862aeac72d0417cc41daafdf968bdb1839 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 18 11:54:57 2024 +0100 c++: Diagnose attributes on class/enum declarations [PR110345] The following testcase shows another issue where we just ignored attributes without telling user we did that. If there are any declarators, the ignoring of the attribute are diagnosed in grokdeclarator etc., but if there is none (and we don't error such as on int; ), the following patch emits diagnostics. 2024-12-18 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * decl.cc (check_tag_decl): Diagnose std_attributes. * g++.dg/cpp0x/gen-attrs-86.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:8b83820b68f358e21c740c0fcfb984e294f81ede commit r15-6330-g8b83820b68f358e21c740c0fcfb984e294f81ede Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 18 11:55:59 2024 +0100 c++: Handle attributes on exception declarations [PR110345] This is a continuation of the series for the ignorability of standard attributes. I've added a test for assume attribute diagnostics appertaining to various entities (mostly invalid) and while doing that, I've discovered that attributes on exception declarations were mostly ignored, this patch adds the missing cp_decl_attributes call and also in the cp_parser_type_specifier_seq case differentiates between attributes and std_attributes to be able to differentiate between attributes which apply to the declaration using type-specifier-seq and attributes after the type specifiers. 2024-12-18 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * parser.cc (cp_parser_type_specifier_seq): Chain cxx11_attribute_p attributes after any type specifier in the is_declaration case to std_attributes rather than attributes. Set also ds_attribute or ds_std_attribute locations if not yet set. (cp_parser_exception_declaration): Pass &type_specifiers.attributes instead of NULL as last argument, call cp_decl_attributes. * g++.dg/cpp0x/attr-assume1.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:17429c1d20568d4810189196d64081139c0d7785 commit r15-6331-g17429c1d20568d4810189196d64081139c0d7785 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 18 11:57:50 2024 +0100 c++: Add carries_dependency further test coverage [PR110345] This patch adds additional test coverage for the carries_dependency attribute (unlike other attributes, the attribute actually isn't implemented for real, so we warn even in the cases of valid uses because we ignore those as well). 2024-12-18 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * g++.dg/cpp0x/attr-carries_dependency2.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:54ea9cfb676d7c2aa593594dfa48147ba7de18e3 commit r15-6332-g54ea9cfb676d7c2aa593594dfa48147ba7de18e3 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 18 11:58:39 2024 +0100 c++: Add fallthrough attribute further test coverage [PR110345] Similarly for fallthrough attribute. Had to add a second testcase because the diagnostics for fallthrough not used within switch at all is done during expansion and expansion won't happen if there are other errors in the testcase. 2024-12-18 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * g++.dg/cpp0x/attr-fallthrough1.C: New test. * g++.dg/cpp0x/attr-fallthrough2.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:190d9a2b384e626bcd0554e01513939af1ed5339 commit r15-6333-g190d9a2b384e626bcd0554e01513939af1ed5339 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 18 11:59:24 2024 +0100 c++: Add {,un}likely attribute further test coverage [PR110345] Similarly for likely/unlikely attributes. 2024-12-18 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * g++.dg/cpp0x/attr-likely1.C: New test. * g++.dg/cpp0x/attr-unlikely1.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:7eb2acb7221b5a219ece1a693d9ac594f229a61a commit r15-6334-g7eb2acb7221b5a219ece1a693d9ac594f229a61a Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 18 12:00:13 2024 +0100 c++: Fix up pedantic handling of alignas [PR110345] The following patch on top of the PR110345 P2552R3 series emits pedantic pedwarns for alignas appertaining to incorrect entities. As the middle-end and attribute exclusions look for "aligned" attribute, the patch transforms alignas into "internal "::aligned attribute (didn't use [[aligned (x)]] so that people can't type it that way). 2024-12-18 Jakub Jelinek <jakub@redhat.com> PR c++/110345 gcc/c-family/ * c-common.h (attr_aligned_exclusions): Declare. (handle_aligned_attribute): Likewise. * c-attribs.cc (handle_aligned_attribute): No longer static. (attr_aligned_exclusions): Use extern instead of static. gcc/cp/ * cp-tree.h (enum cp_tree_index): Add CPTI_INTERNAL_IDENTIFIER. (internal_identifier): Define. (internal_attribute_table): Declare. * parser.cc (cp_parser_exception_declaration): Error on alignas on exception declaration. (cp_parser_std_attribute_spec): Turn alignas into internal ns aligned attribute rather than gnu. * decl.cc (initialize_predefined_identifiers): Initialize internal_identifier. * tree.cc (handle_alignas_attribute): New function. (internal_attributes): New variable. (internal_attribute_table): Likewise. * cp-objcp-common.h (cp_objcp_attribute_table): Add internal_attribute_table entry. gcc/testsuite/ * g++.dg/cpp0x/alignas1.C: Add dg-options "". * g++.dg/cpp0x/alignas2.C: Likewise. * g++.dg/cpp0x/alignas7.C: Likewise. * g++.dg/cpp0x/alignas21.C: New test. * g++.dg/ext/bitfield9.C: Expect a warning. * g++.dg/cpp2a/is-layout-compatible3.C: Add dg-options -pedantic. Expect a warning.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:cd647514a539943ade6461efbf056a7c3f4305c6 commit r15-6384-gcd647514a539943ade6461efbf056a7c3f4305c6 Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Dec 20 10:12:08 2024 +0100 c++: Disallow [[deprecated]] on types other than class/enum definitions [PR110345] For C++ 26 P2552R3 I went through all the spots (except modules) where attribute-specifier-seq appears in the grammar and tried to construct a testcase in all those spots, for now for [[deprecated]] attribute. The patch below contains that testcase. One needed change for this particular attribute was that currently we handle [[deprecated]] exactly the same as [[gnu::deprecated]], but for the latter unlike C++14 or later we allow it also on almost all types, while the standard is strict and allows it only on https://eel.is/c++draft/dcl.attr#deprecated-2 The attribute may be applied to the declaration of a class, a typedef-name, a variable, a non-static data member, a function, a namespace, an enumeration, an enumerator, a concept, or a template specialization. The following patch just adds a pedwarn for the cases that gnu::deprecated allows but C++14 disallows, so integral/floating/boolean types, pointers/references, array types, function types etc. Basically, for TYPE_P, if the attribute is applied in place (which means the struct/union/class/enum definition), it is allowed, otherwise pedwarned. I've tried to compile it also with latest clang and there is agreement in most of the diagnostics, just at block scope (inside of foo) it doesn't diagnose auto e = new int [n] [[deprecated]]; auto e2 = new int [n] [[deprecated]] [42]; [[deprecated]] lab:; and at namespace scope [[deprecated]]; I think that all feels like clang++ bug. Also this pedwarns on [[deprecated]] int : 0; at class scope, that isn't a non-static data member... I guess to mark the paper as implemented (or what has been already voted into C++23 earlier) we'll need to add similar testcase for all the other standard attributes and make sure we check what the attributes can appertain to and what they can't. 2024-12-19 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * parser.cc (cp_parser_std_attribute): Don't transform [[deprecated]] into [[gnu::deprecated]]. * tree.cc (handle_std_deprecated_attribute): New function. (std_attributes): Add deprecated entry. * g++.dg/cpp0x/attr-deprecated1.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:92216cbc59b3a4566d49de5dfa059b70b03d639a commit r15-6385-g92216cbc59b3a4566d49de5dfa059b70b03d639a Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Dec 20 10:17:56 2024 +0100 c++: Fix up maybe_unused attribute handling [PR110345] When adding test coverage for maybe_unused attribute, I've run into several things: 1) similarly to deprecated attribute, the attribute shouldn't pedantically appertain to types other than class/enumeration definitions 2) similarly to deprecated attribute, the attribute shouldn't pedantically appertain to unnamed bit-fields 3) the standard says that it can appertain to identifier labels, but we handled it silently also on case and default labels 4) I've run into a weird spurious error on int f [[maybe_unused]]; int & [[maybe_unused]] i = f; int && [[maybe_unused]] j = 0; The problem was that we create an attribute variant for the int & type, then create an attribute variant for the int && type, and the type_canon_hash hashing just thought those 2 are the same, so used int & [[maybe_unused]] type for j rather than int && [[maybe_unused]]. As TYPE_REF_IS_RVALUE is a flag in the generic code, it was easily possible to hash that flag and compare it 2024-12-19 Jakub Jelinek <jakub@redhat.com> PR c++/110345 gcc/ * tree.cc (type_hash_canon_hash): Hash TYPE_REF_IS_RVALUE for REFERENCE_TYPE. (type_cache_hasher::equal): Compare TYPE_REF_IS_RVALUE for REFERENCE_TYPE. gcc/cp/ * tree.cc (handle_maybe_unused_attribute): New function. (std_attributes): Use handle_maybe_unused_attribute instead of handle_unused_attribute for maybe_unused attribute. gcc/testsuite/ * g++.dg/cpp0x/attr-maybe_unused1.C: New test. * g++.dg/cpp0x/alignas21.C: Add test for int && alignas (int).
I think at this point this is mostly implemented, except that tests for nodiscard/noreturn/no_unique_address https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html weren't reviewed yet. But those only add tests, don't change the FE/middle-end.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:7169ee08203878ba351eedf206df7ff43014d634 commit r15-7391-g7169ee08203878ba351eedf206df7ff43014d634 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Feb 6 18:32:32 2025 +0100 c++: Add nodiscard attribute further test coverage [PR110345] Fairly non-problematic attribute. 2025-02-06 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * g++.dg/cpp0x/attr-nodiscard1.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:122b946cc632e472ee6d828f8adf05567cfaa831 commit r15-7392-g122b946cc632e472ee6d828f8adf05567cfaa831 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Feb 6 18:34:01 2025 +0100 c++: Add noreturn attribute further test coverage [PR110345] Another non-problematic attribute. 2025-02-06 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * g++.dg/cpp0x/attr-noreturn1.C: New test.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:6305c46fad5ae9b3b94b069c040cdd0c67e6e49e commit r15-7393-g6305c46fad5ae9b3b94b069c040cdd0c67e6e49e Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Feb 6 18:35:13 2025 +0100 c++: Add no_unique_address attribute further test coverage [PR110345] Another non-problematic attribute. 2025-02-06 Jakub Jelinek <jakub@redhat.com> PR c++/110345 * g++.dg/cpp0x/attr-no_unique_address1.C: New test.
Implemented for GCC 15.
*** Bug 119043 has been marked as a duplicate of this bug. ***