public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/113802] New: gcc rejects auto f(this auto self...) { }
@ 2024-02-07 10:37 hewillk at gmail dot com
2024-02-15 10:57 ` [Bug c++/113802] " jakub at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: hewillk at gmail dot com @ 2024-02-07 10:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Bug ID: 113802
Summary: gcc rejects auto f(this auto self...) { }
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
struct S {
auto f(this auto self...) { }
};
int main() {
S{}.f();
}
https://godbolt.org/z/a81WPW65f
GCC rejects the above code with:
<source>:2:10: error: an explicit object parameter cannot be a function
parameter pack
2 | auto f(this auto self...) { }
| ^~~~~~~~~~~~~~
But there is no parameter pack here, this should be a variadic function (I
think?)
Only `auto f(this auto...) { }` has parameter pack.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/113802] gcc rejects auto f(this auto self...) { }
2024-02-07 10:37 [Bug c++/113802] New: gcc rejects auto f(this auto self...) { } hewillk at gmail dot com
@ 2024-02-15 10:57 ` jakub at gcc dot gnu.org
2024-02-15 11:25 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-15 10:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org,
| |waffl3x at protonmail dot com
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is that as the comment says, when next token is ellipsis, it isn't
at that point clear if it will be a parameter pack or the odd varargs case
without , before ellipsis.
I've tried
--- gcc/cp/parser.cc.jj 2024-02-14 14:26:19.000000000 +0100
+++ gcc/cp/parser.cc 2024-02-15 11:07:01.706650134 +0100
@@ -25727,17 +25727,10 @@ cp_parser_parameter_declaration (cp_pars
bool const xobj_param_p
= decl_spec_seq_has_spec_p (&decl_specifiers, ds_this);
- if (xobj_param_p
- && ((declarator && declarator->parameter_pack_p)
- || cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)))
+ bool diag_xobj_parameter_pack = false;
+ if (xobj_param_p && (declarator && declarator->parameter_pack_p))
{
- location_t xobj_param
- = make_location (decl_specifiers.locations[ds_this],
- decl_spec_token_start->location,
- input_location);
- error_at (xobj_param,
- "an explicit object parameter cannot "
- "be a function parameter pack");
+ diag_xobj_parameter_pack = true;
/* Suppress errors that occur down the line. */
if (declarator)
declarator->parameter_pack_p = false;
@@ -25755,9 +25748,10 @@ cp_parser_parameter_declaration (cp_pars
(INNERMOST_TEMPLATE_PARMS (current_template_parms));
if (latest_template_parm_idx != template_parm_idx)
- decl_specifiers.type = convert_generic_types_to_packs
- (decl_specifiers.type,
- template_parm_idx, latest_template_parm_idx);
+ decl_specifiers.type
+ = convert_generic_types_to_packs (decl_specifiers.type,
+ template_parm_idx,
+ latest_template_parm_idx);
}
if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
@@ -25775,18 +25769,34 @@ cp_parser_parameter_declaration (cp_pars
{
/* Consume the `...'. */
cp_lexer_consume_token (parser->lexer);
- maybe_warn_variadic_templates ();
-
- /* Build a pack expansion type */
- if (template_parm_p)
- template_parameter_pack_p = true;
- else if (declarator)
- declarator->parameter_pack_p = true;
+ if (xobj_param_p)
+ diag_xobj_parameter_pack = true;
else
- decl_specifiers.type = make_pack_expansion (type);
+ {
+ maybe_warn_variadic_templates ();
+
+ /* Build a pack expansion type */
+ if (template_parm_p)
+ template_parameter_pack_p = true;
+ else if (declarator)
+ declarator->parameter_pack_p = true;
+ else
+ decl_specifiers.type = make_pack_expansion (type);
+ }
}
}
+ if (diag_xobj_parameter_pack)
+ {
+ location_t xobj_param
+ = make_location (decl_specifiers.locations[ds_this],
+ decl_spec_token_start->location,
+ input_location);
+ error_at (xobj_param,
+ "an explicit object parameter cannot "
+ "be a function parameter pack");
+ }
+
/* The restriction on defining new types applies only to the type
of the parameter, not to the default argument. */
parser->type_definition_forbidden_message = saved_message;
and that causes
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 27)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 36)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 47)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 56)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 67)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 76)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 87)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 96)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 107)
FAIL: g++.dg/cpp23/explicit-obj-diagnostics3.C -std=c++23 (test for errors,
line 116)
where presumably those lines are valid, not invalid, but I'm not sure and
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:32:22:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:41:23:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:52:23:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:61:24:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:72:24:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:81:25:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:92:29:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:101:30:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:112:30:
error: parameter packs not expanded with '...':
/usr/src/gcc/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C:121:31:
error: parameter packs not expanded with '...':
excess errors which are an undesirable side-effect.
Ditto for -std=c++26.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/113802] gcc rejects auto f(this auto self...) { }
2024-02-07 10:37 [Bug c++/113802] New: gcc rejects auto f(this auto self...) { } hewillk at gmail dot com
2024-02-15 10:57 ` [Bug c++/113802] " jakub at gcc dot gnu.org
@ 2024-02-15 11:25 ` jakub at gcc dot gnu.org
2024-03-08 8:29 ` cvs-commit at gcc dot gnu.org
2024-03-08 9:00 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-15 11:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-02-15
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57432&action=edit
gcc14-pr113802.patch
Ah, this seems to work.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/113802] gcc rejects auto f(this auto self...) { }
2024-02-07 10:37 [Bug c++/113802] New: gcc rejects auto f(this auto self...) { } hewillk at gmail dot com
2024-02-15 10:57 ` [Bug c++/113802] " jakub at gcc dot gnu.org
2024-02-15 11:25 ` jakub at gcc dot gnu.org
@ 2024-03-08 8:29 ` cvs-commit at gcc dot gnu.org
2024-03-08 9:00 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-08 8:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
--- Comment #3 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:3ecc5071797c4ceb6da67a6c2b2527a046091de2
commit r14-9384-g3ecc5071797c4ceb6da67a6c2b2527a046091de2
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Mar 8 09:11:57 2024 +0100
c++: Fix up parameter pack diagnostics on xobj vs. varargs functions
[PR113802]
The simple presence of ellipsis as next token after the parameter
declaration doesn't imply it is a parameter pack, it sometimes is, e.g.
if its type is a pack, but sometimes is not and in that case it acts
the same as if the next tokens were , ... instead of just ...
The xobj param cannot be a function parameter pack though treats both
the declarator->parameter_pack_p and token->type == CPP_ELLIPSIS as
sufficient conditions for the error. The conditions for CPP_ELLIPSIS
are done a little bit later in the same function and complex enough that
IMHO shouldn't be repeated, on the other side for the
declarator->parameter_pack_p case we clear that flag for xobj params
for error recovery reasons.
This patch just moves the diagnostics later (after the CPP_ELLIPSIS
handling)
and changes the error recovery behavior by pretending the this specifier
didn't appear if an error is reported.
2024-03-08 Jakub Jelinek <jakub@redhat.com>
PR c++/113802
* parser.cc (cp_parser_parameter_declaration): Move the
xobj_param_p
pack diagnostics after ellipsis handling and if an error is
reported,
pretend this specifier didn't appear. Formatting fix.
* g++.dg/cpp23/explicit-obj-diagnostics3.C (S0, S1, S2, S3, S4):
Don't
expect any diagnostics on f and fd member function templates, add
similar templates with ...Selves instead of Selves as k and kd and
expect diagnostics for those. Expect extra diagnostics in error
recovery for g and gd member function templates.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/113802] gcc rejects auto f(this auto self...) { }
2024-02-07 10:37 [Bug c++/113802] New: gcc rejects auto f(this auto self...) { } hewillk at gmail dot com
` (2 preceding siblings ...)
2024-03-08 8:29 ` cvs-commit at gcc dot gnu.org
@ 2024-03-08 9:00 ` jakub at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-03-08 9:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-03-08 9:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-07 10:37 [Bug c++/113802] New: gcc rejects auto f(this auto self...) { } hewillk at gmail dot com
2024-02-15 10:57 ` [Bug c++/113802] " jakub at gcc dot gnu.org
2024-02-15 11:25 ` jakub at gcc dot gnu.org
2024-03-08 8:29 ` cvs-commit at gcc dot gnu.org
2024-03-08 9:00 ` jakub at gcc dot gnu.org
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).