Message ID | 20211201151614.1497902-1-polacek@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B1852385C403 for <patchwork@sourceware.org>; Wed, 1 Dec 2021 15:24:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1852385C403 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1638372286; bh=u8/ozn7u0lhnzLHaIx7fIIsogwDjfDyXyjLPnXTktWk=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=DJFWwnbvPOUJe0JvT6xophI8X4+BR2lgsV7IkkP0178WUfC59RRHNUz1VcrGS4XlE z24rzXLPkupSLN//OYa+a/9fTIy+DJWOWO0AQ10y8vMzQ40ZLW1BNGJ3wLzJYLpmtV D3gmTlmhXAo/vWsx8pNyOtaxuiujJVKVZNgNpk+Y= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 60D14385C410 for <gcc-patches@gcc.gnu.org>; Wed, 1 Dec 2021 15:16:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 60D14385C410 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-351-JrtY9s7MPLG12L4mGjVn4g-1; Wed, 01 Dec 2021 10:16:23 -0500 X-MC-Unique: JrtY9s7MPLG12L4mGjVn4g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D9F1D81CCB4 for <gcc-patches@gcc.gnu.org>; Wed, 1 Dec 2021 15:16:22 +0000 (UTC) Received: from pdp-11.redhat.com (unknown [10.22.17.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id 847E960C0F; Wed, 1 Dec 2021 15:16:22 +0000 (UTC) To: GCC Patches <gcc-patches@gcc.gnu.org>, Jason Merrill <jason@redhat.com> Subject: [PATCH] c++: Handle auto(x) in parameter-declaration-clause [PR103401] Date: Wed, 1 Dec 2021 10:16:14 -0500 Message-Id: <20211201151614.1497902-1-polacek@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-14.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Marek Polacek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Marek Polacek <polacek@redhat.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
c++: Handle auto(x) in parameter-declaration-clause [PR103401]
|
|
Commit Message
Marek Polacek
Dec. 1, 2021, 3:16 p.m. UTC
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
Comments
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
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]); +}