[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503
Alvin Wong changed:
What|Removed |Added
CC||alvinhochun at gmail dot com
--- Comment #6 from Alvin Wong ---
Still a problem with 12.2 / trunk using GNU attributes:
$ <: In lambda function:
:2:47: error: expected '{' before 'noexcept'
: In function 'auto a()':
:2:46: error: expected ';' before 'noexcept'
:2:56: error: expected '(' before '{' token
:2:56: error: expected primary-expression before '{' token
:2:55: error: expected ')' before '{' token
https://godbolt.org/z/xMrb4Pqsj
[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:166c024a1969ca9e77ed450fb65ce5c926a315dc commit r9-8318-g166c024a1969ca9e77ed450fb65ce5c926a315dc Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 c++: Fix attributes with lambda and trailing return type. My fix for 60503 fixed handling of C++11 attributes following the lambda-declarator. My patch for 89640 re-added support for GNU attributes, but attributes after the trailing return type were parsed as applying to the return type rather than to the function. This patch adjusts parsing of a trailing-return-type to ignore GNU attributes at the end of the declaration so that they will be applied to the declaration as a whole. I also considered parsing the attributes between the closing paren and the trailing-return-type, and tried a variety of approaches to implementing that, but I think it's better to stick with the documented rule that "An attribute specifier list may appear immediately before the comma, '=' or semicolon terminating the declaration of an identifier" Anyone disagree? Meanwhile, C++ committee discussion about the lack of any way to apply attributes to a lambda op() seems to have concluded that they should go between the introducer and declarator, so I've implemented that as well. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/90333 PR c++/89640 PR c++/60503 * parser.c (cp_parser_type_specifier_seq): Don't parse attributes in a trailing return type. (cp_parser_lambda_declarator_opt): Parse C++11 attributes before parens.
[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:245e40af4fab5b7cf40fb310591a879355775971 commit r10-6335-g245e40af4fab5b7cf40fb310591a879355775971 Author: Jason Merrill Date: Tue Jan 28 17:41:05 2020 -0500 c++: Fix attributes with lambda and trailing return type. My fix for 60503 fixed handling of C++11 attributes following the lambda-declarator. My patch for 89640 re-added support for GNU attributes, but attributes after the trailing return type were parsed as applying to the return type rather than to the function. This patch adjusts parsing of a trailing-return-type to ignore GNU attributes at the end of the declaration so that they will be applied to the declaration as a whole. I also considered parsing the attributes between the closing paren and the trailing-return-type, and tried a variety of approaches to implementing that, but I think it's better to stick with the documented rule that "An attribute specifier list may appear immediately before the comma, '=' or semicolon terminating the declaration of an identifier" Anyone disagree? Meanwhile, C++ committee discussion about the lack of any way to apply attributes to a lambda op() seems to have concluded that they should go between the introducer and declarator, so I've implemented that as well. PR c++/90333 PR c++/89640 PR c++/60503 * parser.c (cp_parser_type_specifier_seq): Don't parse attributes in a trailing return type. (cp_parser_lambda_declarator_opt): Parse C++11 attributes before parens.
[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Mar 18 19:34:47 2019 New Revision: 269775 URL: https://gcc.gnu.org/viewcvs?rev=269775=gcc=rev Log: PR c++/89640 - GNU attributes on lambda. My patch for PR 60503 to fix C++11 attribute parsing on lambdas accidentally removed support for GNU attributes. * parser.c (cp_parser_lambda_declarator_opt): Allow GNU attributes. Added: trunk/gcc/testsuite/g++.dg/ext/attr-lambda1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Can the bug be marked as resolved?
[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503 --- Comment #1 from Jason Merrill --- Author: jason Date: Mon Nov 5 07:46:52 2018 New Revision: 265787 URL: https://gcc.gnu.org/viewcvs?rev=265787=gcc=rev Log: PR c++/60503 - wrong lambda attribute syntax. This patch fixes two issues with lambda attribute handling: First, it was in the wrong place in the grammar. Second, it was treating attributes as applying to the whole declaration rather than to the function type, as specified by the standard. * parser.c (cp_parser_lambda_declarator_opt): Fix attribute handling. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-attr1.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-attr2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-24 Ever confirmed|0 |1
