c++: Handle auto(x) in parameter-declaration-clause [PR103401]

  In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
so

  void f(decltype(auto(0)));

should be just as

  void f(int);

but currently, everytime we see 'auto' in a parameter-declaration-clause,
we try to synthesize_implicit_template_parm for it, creating a new template
parameter list.  The code above actually has us calling s_i_t_p twice;
once from cp_parser_decltype_expr -> cp_parser_postfix_expression which
fails and then again from cp_parser_decltype_expr -> cp_parser_expression.
So it looks like we have f<auto, auto> and we accept ill-formed code.

So we need to be more careful about synthesizing the implicit template
parameter.  cp_parser_postfix_expression looked like a sensible place.

The r11-1913 change is OK: we need to make sure that we see '(auto)' after
decltype to go ahead with 'decltype(auto)'.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

	PR c++/103401

gcc/cp/ChangeLog:

	* parser.c (cp_parser_postfix_expression): Set
	auto_is_implicit_function_template_parm_p when parsing a postfix
	expression.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/auto-fncast7.C: New test.
	* g++.dg/cpp23/auto-fncast8.C: New test.
---
 gcc/cp/parser.c                           |  2 ++
 gcc/testsuite/g++.dg/cpp23/auto-fncast7.C |  9 ++++++++
 gcc/testsuite/g++.dg/cpp23/auto-fncast8.C | 28 +++++++++++++++++++++++
 3 files changed, 39 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast7.C
 create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast8.C


base-commit: e5440bc08e07fd491dcccd47e1b86a5985ee117c
  

On 12/1/21 10:16, Marek Polacek wrote:
> In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
> so
> 
>    void f(decltype(auto(0)));
> 
> should be just as
> 
>    void f(int);
> 
> but currently, everytime we see 'auto' in a parameter-declaration-clause,
> we try to synthesize_implicit_template_parm for it, creating a new template
> parameter list.  The code above actually has us calling s_i_t_p twice;
> once from cp_parser_decltype_expr -> cp_parser_postfix_expression which
> fails and then again from cp_parser_decltype_expr -> cp_parser_expression.
> So it looks like we have f<auto, auto> and we accept ill-formed code.
> 
> So we need to be more careful about synthesizing the implicit template
> parameter.  cp_parser_postfix_expression looked like a sensible place.

Does this cover other uses of auto in decltype, such as

void f(decltype(new auto{0}));

?  Should we adjust this flag in cp_parser_decltype along with all the 
other flags?

> The r11-1913 change is OK: we need to make sure that we see '(auto)' after
> decltype to go ahead with 'decltype(auto)'.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
> 	PR c++/103401
> 
> gcc/cp/ChangeLog:
> 
> 	* parser.c (cp_parser_postfix_expression): Set
> 	auto_is_implicit_function_template_parm_p when parsing a postfix
> 	expression.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/cpp23/auto-fncast7.C: New test.
> 	* g++.dg/cpp23/auto-fncast8.C: New test.
> ---
>   gcc/cp/parser.c                           |  2 ++
>   gcc/testsuite/g++.dg/cpp23/auto-fncast7.C |  9 ++++++++
>   gcc/testsuite/g++.dg/cpp23/auto-fncast8.C | 28 +++++++++++++++++++++++
>   3 files changed, 39 insertions(+)
>   create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast7.C
>   create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast8.C
> 
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 55e6a1a8b3a..c43b180f888 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -7508,6 +7508,8 @@ cp_parser_postfix_expression (cp_parser *parser, bool address_p, bool cast_p,
>   	   looking at a functional cast.  We could also be looking at
>   	   an id-expression.  So, we try the functional cast, and if
>   	   that doesn't work we fall back to the primary-expression.  */
> +	auto cleanup = make_temp_override
> +	  (parser->auto_is_implicit_function_template_parm_p, false);
>   	cp_parser_parse_tentatively (parser);
>   	/* Look for the simple-type-specifier.  */
>           ++parser->prevent_constrained_type_specifiers;
> diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast7.C b/gcc/testsuite/g++.dg/cpp23/auto-fncast7.C
> new file mode 100644
> index 00000000000..763164f3e5b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast7.C
> @@ -0,0 +1,9 @@
> +// PR c++/103401
> +// { dg-do compile { target c++23 } }
> +
> +void f(decltype(auto(0))) { }
> +
> +int main()
> +{
> +  f<int,int>(0); // { dg-error "no matching function" }
> +}
> diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast8.C b/gcc/testsuite/g++.dg/cpp23/auto-fncast8.C
> new file mode 100644
> index 00000000000..760827a5d6e
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast8.C
> @@ -0,0 +1,28 @@
> +// PR c++/103401
> +// { dg-do compile { target c++23 } }
> +
> +void f1 (decltype(auto(0)));
> +void f2 (decltype(auto{0}));
> +void f3 (int = auto(42));
> +void f4 (int = auto{42});
> +void f5 (decltype(auto(0)) = auto(42));
> +void f6 (auto (x));
> +void f7 (int[auto(10)]);
> +void f8 (int[auto{10}]);
> +
> +void
> +g ()
> +{
> +  f1 (1);
> +  f2 (1);
> +  f3 ();
> +  f3 (1);
> +  f4 ();
> +  f4 (1);
> +  f5 ();
> +  f5 (1);
> +  f6 ('a');
> +  int a[10];
> +  f7 (&a[0]);
> +  f8 (&a[0]);
> +}
> 
> base-commit: e5440bc08e07fd491dcccd47e1b86a5985ee117c
>
  

On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote:
> On 12/1/21 10:16, Marek Polacek wrote:
> > In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
> > so
> > 
> >    void f(decltype(auto(0)));
> > 
> > should be just as
> > 
> >    void f(int);
> > 
> > but currently, everytime we see 'auto' in a parameter-declaration-clause,
> > we try to synthesize_implicit_template_parm for it, creating a new template
> > parameter list.  The code above actually has us calling s_i_t_p twice;
> > once from cp_parser_decltype_expr -> cp_parser_postfix_expression which
> > fails and then again from cp_parser_decltype_expr -> cp_parser_expression.
> > So it looks like we have f<auto, auto> and we accept ill-formed code.
> > 
> > So we need to be more careful about synthesizing the implicit template
> > parameter.  cp_parser_postfix_expression looked like a sensible place.
> 
> Does this cover other uses of auto in decltype, such as
> 
> void f(decltype(new auto{0}));

Yes: the clearing of auto_is_implicit_function_template_parm_p will happen here
too.

However, I'm noticing this:

  void f1(decltype(new auto{0}));
  void f2(decltype(new int{0}));

  void
  g ()
  {
    int i;
    void f3(decltype(new auto{0}));
    void f4(decltype(new int{0}));
    f1 (&i); // error: no matching function for call to f1(int*)
             // couldn't deduce template parameter auto:1
    f2 (&i);
    f3 (&i);
    f4 (&i);
  }
 
I think the error we issue is bogus.  (My patch doesn't change this.  clang++
accepts.)  Should I file a PR (and investigate)?

> ?  Should we adjust this flag in cp_parser_decltype along with all the other
> flags?

I think that's possible, but wouldn't cover auto in default arguments, or array
bounds.
 
Thanks,

Marek
  

On 12/2/21 10:27, Marek Polacek wrote:
> On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote:
>> On 12/1/21 10:16, Marek Polacek wrote:
>>> In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
>>> so
>>>
>>>     void f(decltype(auto(0)));
>>>
>>> should be just as
>>>
>>>     void f(int);
>>>
>>> but currently, everytime we see 'auto' in a parameter-declaration-clause,
>>> we try to synthesize_implicit_template_parm for it, creating a new template
>>> parameter list.  The code above actually has us calling s_i_t_p twice;
>>> once from cp_parser_decltype_expr -> cp_parser_postfix_expression which
>>> fails and then again from cp_parser_decltype_expr -> cp_parser_expression.
>>> So it looks like we have f<auto, auto> and we accept ill-formed code.
>>>
>>> So we need to be more careful about synthesizing the implicit template
>>> parameter.  cp_parser_postfix_expression looked like a sensible place.
>>
>> Does this cover other uses of auto in decltype, such as
>>
>> void f(decltype(new auto{0}));
> 
> Yes: the clearing of auto_is_implicit_function_template_parm_p will happen here
> too.
> 
> However, I'm noticing this:
> 
>    void f1(decltype(new auto{0}));
>    void f2(decltype(new int{0}));
> 
>    void
>    g ()
>    {
>      int i;
>      void f3(decltype(new auto{0}));
>      void f4(decltype(new int{0}));
>      f1 (&i); // error: no matching function for call to f1(int*)
>               // couldn't deduce template parameter auto:1
>      f2 (&i);
>      f3 (&i);
>      f4 (&i);
>    }
>   
> I think the error we issue is bogus.  (My patch doesn't change this.  clang++
> accepts.)  Should I file a PR (and investigate)?

That certainly suggests that auto_is_implicit_function_template_parm_p 
isn't getting cleared soon enough for f1.

>> ?  Should we adjust this flag in cp_parser_decltype along with all the other
>> flags?
> 
> I think that's possible, but wouldn't cover auto in default arguments, or array
> bounds.

I guess cp_parser_sizeof_operand would need the same change.

Do we currently handle auto in default arguments wrong?  Ah, I see that 
we currently set auto_is_... for the whole parameter declaration clause, 
rather than just for the decl-specifier-seq of parameters as the 
standard specifies:

"A placeholder-type-specifier of the form type-constraint opt auto can 
be used as a decl-specifier of the decl-specifier-seq of a 
parameter-declaration of a function declaration or lambda-expression...."

Jason