[Bug c++/113788] New: Deducing this is broken with structured binding

[Bug c++/113788] New: Deducing this is broken with structured binding

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

            Bug ID: 113788
           Summary: Deducing this is broken with structured binding
           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: ---

GCC accepts the following:

struct S {
  int a, b;
};

int main() {
  S s = {1, 2};
  this auto& [a, b] = s;
  return b;
}

Thanks.

https://godbolt.org/z/34xTee6sx

[Bug c++/113788] Deducing this is broken with structured binding

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-06
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |mpolacek at gcc dot gnu.org

[Bug c++/113788] Deducing this is broken with structured binding

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems it is far more cases where we allow it:
struct S { int a, b; };
struct U {
  void foo () { this int g = 1; }
};
this auto h = 1;

int
main ()
{
  S s = { 1, 2 };
  short t[3] = { 3, 4, 5 };
  this auto &[a, b] = s;
  this auto &[c, d, e] = t;
  this int f = 1;
  for (this auto &i : t)
    ;
}

[Bug c++/113788] Deducing this is broken with structured binding

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Yes, seems that currently we only check that it's the first specifier:

      /* Special case for "this" specifier, indicating a parm is an xobj parm.
         The "this" specifier must be the first specifier in the declaration,
         after any attributes.  */
      if (token->keyword == RID_THIS)
        {     
          cp_lexer_consume_token (parser->lexer);
          if (token != first_specifier)

but I guess we should also check we're processing a parameter-declaration.

[Bug c++/113788] Deducing this is broken with structured binding

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, given that this[opt] is not in the grammar as declaration specifier but
only in parameter-declaration, I'd go with:
--- parser.cc.jj2       2024-01-17 10:34:45.337660930 +0100
+++ parser.cc   2024-02-06 18:31:35.587193903 +0100
@@ -2088,7 +2088,9 @@ enum
   /* When parsing of the noexcept-specifier should be delayed.  */
   CP_PARSER_FLAGS_DELAY_NOEXCEPT = 0x40,
   /* When parsing a consteval declarator.  */
-  CP_PARSER_FLAGS_CONSTEVAL = 0x80
+  CP_PARSER_FLAGS_CONSTEVAL = 0x80,
+  /* When parsing a parameter declaration.  */
+  CP_PARSER_FLAGS_PARAMETER = 0x100
 };

 /* This type is used for parameters and variables which hold
@@ -16342,7 +16344,7 @@ cp_parser_decl_specifier_seq (cp_parser*
       /* Special case for "this" specifier, indicating a parm is an xobj parm.
         The "this" specifier must be the first specifier in the declaration,
         after any attributes.  */
-      if (token->keyword == RID_THIS)
+      if (token->keyword == RID_THIS && (flags & CP_PARSER_FLAGS_PARAMETER))
        {
          cp_lexer_consume_token (parser->lexer);
          if (token != first_specifier)
@@ -25607,7 +25609,7 @@ cp_parser_parameter_declaration (cp_pars
   /* Parse the declaration-specifiers.  */
   cp_token *decl_spec_token_start = cp_lexer_peek_token (parser->lexer);
   cp_parser_decl_specifier_seq (parser,
-                               flags,
+                               flags | CP_PARSER_FLAGS_PARAMETER,
                                &decl_specifiers,
                                &declares_class_or_enum);

[Bug c++/113788] Deducing this is broken with structured binding

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57343&action=edit
gcc14-pr113788.patch

So far very lightly tested patch (just dg.exp='pr113788.C explicit-obj*.C').

[Bug c++/113788] Deducing this is broken with structured binding

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

--- Comment #5 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:40485378ade83102d7aa30c317f5d6c90c1d232b

commit r14-8832-g40485378ade83102d7aa30c317f5d6c90c1d232b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 6 22:34:55 2024 +0100

    c++: Disallow this specifier except for parameter declarations [PR113788]

    The deducing this patchset added parsing of this specifier to
    cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar
    this[opt] only appears in the parameter-declaration non-terminal, so
    rather than checking in all the callers of cp_parser_decl_specifier_seq
    except for cp_parser_parameter_declaration that this specifier didn't
    appear I think it is far easier and closer to what the standard says
    to only parse this specifier when called from
    cp_parser_parameter_declaration.

    2024-02-06  Jakub Jelinek  <jakub@redhat.com>

            PR c++/113788
            * parser.cc (CP_PARSER_FLAGS_PARAMETER): New enumerator.
            (cp_parser_decl_specifier_seq): Parse RID_THIS only if
            CP_PARSER_FLAGS_PARAMETER is set in flags.
            (cp_parser_parameter_declaration): Or in CP_PARSER_FLAGS_PARAMETER
            when calling cp_parser_decl_specifier_seq.

            * g++.dg/parse/pr113788.C: New test.

[Bug c++/113788] Deducing this is broken with structured binding

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug c++/113788] Deducing this is broken with structured binding

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
"broken with structured binding" doesn't seem accurate. It works fine, there
were just some ill-formed cases that should have given errors.