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).