| Message ID | ZU7VOhuVUvCPnqqG@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] c++: fix parsing with auto(x) [PR112410] | expand |
On 11/10/23 20:13, Marek Polacek wrote: > On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote: >> On 11/9/23 14:58, Marek Polacek wrote: >>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>> >>> -- >8 -- >>> Here we are wrongly parsing >>> >>> int y(auto(42)); >>> >>> which uses the C++23 cast-to-prvalue feature, and initializes y to 42. >>> However, we were treating the auto as an implicit template parameter. >>> >>> Fixing the auto{42} case is easy, but when auto is followed by a (, >>> I found the fix to be much more involved. For instance, we cannot >>> use cp_parser_expression, because that can give hard errors. It's >>> also necessary to disambiguate 'auto(i)' as 'auto i', not a cast. >>> auto(), auto(int), auto(f)(int), auto(*), auto(i[]), auto(...), etc. >>> are all function declarations. We have to look at more than one >>> token to decide. >> >> Yeah, this is a most vexing parse problem. The code is synthesizing >> template parameters before we've resolved whether the auto is a >> decl-specifier or not. >> >>> In this fix, I'm (ab)using cp_parser_declarator, with member_p=false >>> so that it doesn't commit. But it handles even more complicated >>> cases as >>> >>> int fn (auto (*const **&f)(int) -> char); >> >> But it doesn't seem to handle the extremely vexing >> >> struct A { >> A(int,int); >> }; >> >> int main() >> { >> int a; >> A b(auto(a), 42); >> } > > Argh. This test should indeed be accepted and is currently rejected, > but it's a different problem: 'b' is at block scope and you can't > have a template there. But when I put it into a namespace scope, > it shows that my patch doesn't work correctly. I've added auto-fncast14.C > for the latter and opened c++/112482 for the block-scope problem. > >> I think we need to stop synthesizing immediately when we see RID_AUTO, and >> instead go back after we successfully parse a declaration and synthesize for >> any autos we saw along the way. :/ > > That seems very complicated :(. I had a different idea though; how > about the following patch? The idea is that if we see that parsing > the parameter-declaration-list didn't work, we undo what synthesize_ > did, and let cp_parser_initializer parse "(auto(42))", which should > succeed. I checked that after cp_finish_decl y is initialized to 42. Nice, that's much simpler. Do you also still need the changes to cp_parser_simple_type_specifier? > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > Here we are wrongly parsing > > int y(auto(42)); > > which uses the C++23 cast-to-prvalue feature, and initializes y to 42. > However, we were treating the auto as an implicit template parameter. > > Fixing the auto{42} case is easy, but when auto is followed by a (, > I found the fix to be much more involved. For instance, we cannot > use cp_parser_expression, because that can give hard errors. It's > also necessary to disambiguate 'auto(i)' as 'auto i', not a cast. > auto(), auto(int), auto(f)(int), auto(*), auto(i[]), auto(...), etc. > are all function declarations. > > This patch rectifies that by undoing the implicit function template > modification. In the test above, we should notice that the parameter > list is ill-formed, and since we've synthesized an implicit template > parameter, we undo it by calling abort_fully_implicit_template. Then, > we'll parse the "(auto(42))" as an initializer. > > PR c++/112410 > > gcc/cp/ChangeLog: > > * parser.cc (cp_parser_simple_type_specifier): Disambiguate > between a variable and function declaration with auto. > (cp_parser_parameter_declaration_clause): Maybe call > abort_fully_implicit_template if it turned out the parameter list was > ill-formed. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp23/auto-fncast13.C: New test. > * g++.dg/cpp23/auto-fncast14.C: New test. > --- > gcc/cp/parser.cc | 27 +++++++++- > gcc/testsuite/g++.dg/cpp23/auto-fncast13.C | 61 ++++++++++++++++++++++ > gcc/testsuite/g++.dg/cpp23/auto-fncast14.C | 9 ++++ > 3 files changed, 96 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast13.C > create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast14.C > > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc > index 5116bcb78f6..947351b09b8 100644 > --- a/gcc/cp/parser.cc > +++ b/gcc/cp/parser.cc > @@ -19991,6 +19991,8 @@ cp_parser_simple_type_specifier (cp_parser* parser, > /* The 'auto' might be the placeholder return type for a function decl > with trailing return type. */ > bool have_trailing_return_fn_decl = false; > + /* Or it might be auto(x) or auto {x}. */ > + bool decay_copy = false; > > cp_parser_parse_tentatively (parser); > cp_lexer_consume_token (parser->lexer); > @@ -20008,6 +20010,11 @@ cp_parser_simple_type_specifier (cp_parser* parser, > /*consume_paren*/true); > continue; > } > + else if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE)) > + { > + decay_copy = true; > + break; > + } > > if (cp_lexer_next_token_is (parser->lexer, CPP_DEREF)) > { > @@ -20019,6 +20026,11 @@ cp_parser_simple_type_specifier (cp_parser* parser, > } > cp_parser_abort_tentative_parse (parser); > > + if (decay_copy) > + { > + type = error_mark_node; > + break; > + } > if (have_trailing_return_fn_decl) > { > type = make_auto (); > @@ -24973,7 +24985,20 @@ cp_parser_parameter_declaration_clause (cp_parser* parser, > parameter-declaration-list, then the entire > parameter-declaration-clause is erroneous. */ > if (parameters == error_mark_node) > - return NULL_TREE; > + { > + /* For code like > + int x(auto(42)); > + A a(auto(i), 42); > + we have synthesized an implicit template parameter and marked > + what we thought was a function as an implicit function template. > + But now, having seen the whole parameter list, we know it's not > + a function declaration, so undo that. */ > + if (parser->fully_implicit_function_template_p > + /* Don't do this for the inner (). */ > + && parser->default_arg_ok_p) > + abort_fully_implicit_template (parser); > + return NULL_TREE; > + } > > /* Peek at the next token. */ > token = cp_lexer_peek_token (parser->lexer); > diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast13.C b/gcc/testsuite/g++.dg/cpp23/auto-fncast13.C > new file mode 100644 > index 00000000000..1bceffb70cf > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast13.C > @@ -0,0 +1,61 @@ > +// PR c++/112410 > +// { dg-do compile { target c++23 } } > + > +int f1 (auto(int) -> char); > +int f2 (auto x); > +int f3 (auto); > +int f4 (auto(i)); > + > +int v1 (auto(42)); > +int v2 (auto{42}); > +int e1 (auto{i}); // { dg-error "not declared" } > +int i; > +int v3 (auto{i}); > +int v4 (auto(i + 1)); > +int v5 (auto(+i)); > +int v6 (auto(i = 4)); > + > +int f5 (auto(i)); > +int f6 (auto()); > +int f7 (auto(int)); > +int f8 (auto(f)(int)); > +int f9 (auto(...) -> char); > +// FIXME: ICEs (PR c++/89867) > +//int f10 (auto(__attribute__((unused)) i)); > +int f11 (auto((i))); > +int f12 (auto(i[])); > +int f13 (auto(*i)); > +int f14 (auto(*)); > + > +int e2 (auto{}); // { dg-error "invalid use of .auto." } > +int e3 (auto(i, i)); // { dg-error "invalid use of .auto." } > + > +char bar (int); > +char baz (); > +char qux (...); > + > +void > +g (int i) > +{ > + f1 (bar); > + f2 (42); > + f3 (42); > + f4 (42); > + f5 (42); > + f6 (baz); > + f7 (bar); > + f8 (bar); > + f9 (qux); > +// f10 (42); > + f11 (42); > + f12 (&i); > + f13 (&i); > + f14 (&i); > + > + v1 = 1; > + v2 = 2; > + v3 = 3; > + v4 = 4; > + v5 = 5; > + v6 = 6; > +} > diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast14.C b/gcc/testsuite/g++.dg/cpp23/auto-fncast14.C > new file mode 100644 > index 00000000000..9e7a06c87d5 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast14.C > @@ -0,0 +1,9 @@ > +// PR c++/112410 > +// { dg-do compile { target c++23 } } > + > +struct A { > + A(int,int); > +}; > + > +int a; > +A b1(auto(a), 42); > > base-commit: e0c1476d5d7c450b1b16a40364cea4e91237ea93
On Mon, Nov 13, 2023 at 09:26:41PM -0500, Jason Merrill wrote: > On 11/10/23 20:13, Marek Polacek wrote: > > On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote: > > > On 11/9/23 14:58, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > -- >8 -- > > > > Here we are wrongly parsing > > > > > > > > int y(auto(42)); > > > > > > > > which uses the C++23 cast-to-prvalue feature, and initializes y to 42. > > > > However, we were treating the auto as an implicit template parameter. > > > > > > > > Fixing the auto{42} case is easy, but when auto is followed by a (, > > > > I found the fix to be much more involved. For instance, we cannot > > > > use cp_parser_expression, because that can give hard errors. It's > > > > also necessary to disambiguate 'auto(i)' as 'auto i', not a cast. > > > > auto(), auto(int), auto(f)(int), auto(*), auto(i[]), auto(...), etc. > > > > are all function declarations. We have to look at more than one > > > > token to decide. > > > > > > Yeah, this is a most vexing parse problem. The code is synthesizing > > > template parameters before we've resolved whether the auto is a > > > decl-specifier or not. > > > > > > > In this fix, I'm (ab)using cp_parser_declarator, with member_p=false > > > > so that it doesn't commit. But it handles even more complicated > > > > cases as > > > > > > > > int fn (auto (*const **&f)(int) -> char); > > > > > > But it doesn't seem to handle the extremely vexing > > > > > > struct A { > > > A(int,int); > > > }; > > > > > > int main() > > > { > > > int a; > > > A b(auto(a), 42); > > > } > > > > Argh. This test should indeed be accepted and is currently rejected, > > but it's a different problem: 'b' is at block scope and you can't > > have a template there. But when I put it into a namespace scope, > > it shows that my patch doesn't work correctly. I've added auto-fncast14.C > > for the latter and opened c++/112482 for the block-scope problem. > > > I think we need to stop synthesizing immediately when we see RID_AUTO, and > > > instead go back after we successfully parse a declaration and synthesize for > > > any autos we saw along the way. :/ > > > > That seems very complicated :(. I had a different idea though; how > > about the following patch? The idea is that if we see that parsing > > the parameter-declaration-list didn't work, we undo what synthesize_ > > did, and let cp_parser_initializer parse "(auto(42))", which should > > succeed. I checked that after cp_finish_decl y is initialized to 42. > > Nice, that's much simpler. Do you also still need the changes to > cp_parser_simple_type_specifier? I do, otherwise we parse int f (auto{42}); just as if it had been int f (auto); because the {42} is consumed in the cp_parser_simple_type_specifier/RID_AUTO loop. :/ Marek
On 11/14/23 10:58, Marek Polacek wrote: > On Mon, Nov 13, 2023 at 09:26:41PM -0500, Jason Merrill wrote: >> On 11/10/23 20:13, Marek Polacek wrote: >>> On Thu, Nov 09, 2023 at 07:07:03PM -0500, Jason Merrill wrote: >>>> On 11/9/23 14:58, Marek Polacek wrote: >>>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>>>> >>>>> -- >8 -- >>>>> Here we are wrongly parsing >>>>> >>>>> int y(auto(42)); >>>>> >>>>> which uses the C++23 cast-to-prvalue feature, and initializes y to 42. >>>>> However, we were treating the auto as an implicit template parameter. >>>>> >>>>> Fixing the auto{42} case is easy, but when auto is followed by a (, >>>>> I found the fix to be much more involved. For instance, we cannot >>>>> use cp_parser_expression, because that can give hard errors. It's >>>>> also necessary to disambiguate 'auto(i)' as 'auto i', not a cast. >>>>> auto(), auto(int), auto(f)(int), auto(*), auto(i[]), auto(...), etc. >>>>> are all function declarations. We have to look at more than one >>>>> token to decide. >>>> >>>> Yeah, this is a most vexing parse problem. The code is synthesizing >>>> template parameters before we've resolved whether the auto is a >>>> decl-specifier or not. >>>> >>>>> In this fix, I'm (ab)using cp_parser_declarator, with member_p=false >>>>> so that it doesn't commit. But it handles even more complicated >>>>> cases as >>>>> >>>>> int fn (auto (*const **&f)(int) -> char); >>>> >>>> But it doesn't seem to handle the extremely vexing >>>> >>>> struct A { >>>> A(int,int); >>>> }; >>>> >>>> int main() >>>> { >>>> int a; >>>> A b(auto(a), 42); >>>> } >>> >>> Argh. This test should indeed be accepted and is currently rejected, >>> but it's a different problem: 'b' is at block scope and you can't >>> have a template there. But when I put it into a namespace scope, >>> it shows that my patch doesn't work correctly. I've added auto-fncast14.C >>> for the latter and opened c++/112482 for the block-scope problem. >>>> I think we need to stop synthesizing immediately when we see RID_AUTO, and >>>> instead go back after we successfully parse a declaration and synthesize for >>>> any autos we saw along the way. :/ >>> >>> That seems very complicated :(. I had a different idea though; how >>> about the following patch? The idea is that if we see that parsing >>> the parameter-declaration-list didn't work, we undo what synthesize_ >>> did, and let cp_parser_initializer parse "(auto(42))", which should >>> succeed. I checked that after cp_finish_decl y is initialized to 42. >> >> Nice, that's much simpler. Do you also still need the changes to >> cp_parser_simple_type_specifier? > > I do, otherwise we parse > > int f (auto{42}); > > just as if it had been > > int f (auto); > > because the {42} is consumed in the cp_parser_simple_type_specifier/RID_AUTO > loop. :/ It isn't consumed there, that loop is just scanning forward to see if there's a ->. The { is still the next token when we expect it to be a closing ) in cp_parser_direct_declarator: > /* Parse the parameter-declaration-clause. */ > params > = cp_parser_parameter_declaration_clause (parser, flags); > const location_t parens_end > = cp_lexer_peek_token (parser->lexer)->location; > > /* Consume the `)'. */ > parens.require_close (parser); Maybe we want to abort_fully_implicit_template here rather than in cp_parser_parameter_declaration_clause? Jason
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc index 5116bcb78f6..947351b09b8 100644 --- a/gcc/cp/parser.cc +++ b/gcc/cp/parser.cc @@ -19991,6 +19991,8 @@ cp_parser_simple_type_specifier (cp_parser* parser, /* The 'auto' might be the placeholder return type for a function decl with trailing return type. */ bool have_trailing_return_fn_decl = false; + /* Or it might be auto(x) or auto {x}. */ + bool decay_copy = false; cp_parser_parse_tentatively (parser); cp_lexer_consume_token (parser->lexer); @@ -20008,6 +20010,11 @@ cp_parser_simple_type_specifier (cp_parser* parser, /*consume_paren*/true); continue; } + else if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE)) + { + decay_copy = true; + break; + } if (cp_lexer_next_token_is (parser->lexer, CPP_DEREF)) { @@ -20019,6 +20026,11 @@ cp_parser_simple_type_specifier (cp_parser* parser, } cp_parser_abort_tentative_parse (parser); + if (decay_copy) + { + type = error_mark_node; + break; + } if (have_trailing_return_fn_decl) { type = make_auto (); @@ -24973,7 +24985,20 @@ cp_parser_parameter_declaration_clause (cp_parser* parser, parameter-declaration-list, then the entire parameter-declaration-clause is erroneous. */ if (parameters == error_mark_node) - return NULL_TREE; + { + /* For code like + int x(auto(42)); + A a(auto(i), 42); + we have synthesized an implicit template parameter and marked + what we thought was a function as an implicit function template. + But now, having seen the whole parameter list, we know it's not + a function declaration, so undo that. */ + if (parser->fully_implicit_function_template_p + /* Don't do this for the inner (). */ + && parser->default_arg_ok_p) + abort_fully_implicit_template (parser); + return NULL_TREE; + } /* Peek at the next token. */ token = cp_lexer_peek_token (parser->lexer); diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast13.C b/gcc/testsuite/g++.dg/cpp23/auto-fncast13.C new file mode 100644 index 00000000000..1bceffb70cf --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast13.C @@ -0,0 +1,61 @@ +// PR c++/112410 +// { dg-do compile { target c++23 } } + +int f1 (auto(int) -> char); +int f2 (auto x); +int f3 (auto); +int f4 (auto(i)); + +int v1 (auto(42)); +int v2 (auto{42}); +int e1 (auto{i}); // { dg-error "not declared" } +int i; +int v3 (auto{i}); +int v4 (auto(i + 1)); +int v5 (auto(+i)); +int v6 (auto(i = 4)); + +int f5 (auto(i)); +int f6 (auto()); +int f7 (auto(int)); +int f8 (auto(f)(int)); +int f9 (auto(...) -> char); +// FIXME: ICEs (PR c++/89867) +//int f10 (auto(__attribute__((unused)) i)); +int f11 (auto((i))); +int f12 (auto(i[])); +int f13 (auto(*i)); +int f14 (auto(*)); + +int e2 (auto{}); // { dg-error "invalid use of .auto." } +int e3 (auto(i, i)); // { dg-error "invalid use of .auto." } + +char bar (int); +char baz (); +char qux (...); + +void +g (int i) +{ + f1 (bar); + f2 (42); + f3 (42); + f4 (42); + f5 (42); + f6 (baz); + f7 (bar); + f8 (bar); + f9 (qux); +// f10 (42); + f11 (42); + f12 (&i); + f13 (&i); + f14 (&i); + + v1 = 1; + v2 = 2; + v3 = 3; + v4 = 4; + v5 = 5; + v6 = 6; +} diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast14.C b/gcc/testsuite/g++.dg/cpp23/auto-fncast14.C new file mode 100644 index 00000000000..9e7a06c87d5 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast14.C @@ -0,0 +1,9 @@ +// PR c++/112410 +// { dg-do compile { target c++23 } } + +struct A { + A(int,int); +}; + +int a; +A b1(auto(a), 42);