From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9426 invoked by alias); 21 Mar 2018 21:54:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 9415 invoked by uid 89); 21 Mar 2018 21:54:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Mar 2018 21:54:50 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C898F97848 for ; Wed, 21 Mar 2018 21:54:48 +0000 (UTC) Received: from free.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 790958CA59; Wed, 21 Mar 2018 21:54:38 +0000 (UTC) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTP id w2LLsWBp230655; Wed, 21 Mar 2018 18:54:32 -0300 From: Alexandre Oliva To: Jason Merrill Cc: gcc-patches List Subject: Re: [PATCH] [PR c++/71965] silence multi-dim array init sorry without tf_error References: Date: Wed, 21 Mar 2018 22:16:00 -0000 In-Reply-To: (Jason Merrill's message of "Tue, 20 Mar 2018 18:00:40 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-03/txt/msg01144.txt.bz2 On Mar 20, 2018, Jason Merrill wrote: >> + if ((complain & tf_error)) >> + error ("cannot initialize multi-dimensional" >> + " array with initializer"); > Let's also use the other diagnostic message: "array must be > initialized with a brace-enclosed initializer". > OK with that change. Thanks. Besides changing the message, I added the location of the initializer to the message. Here's what I'm checking in: [PR c++/71965] silence multi-dim array init sorry without tf_error We shouldn't substitute templates into short-circuited-out concepts constraints, but we do, and to add insult to injury, we issue a sorry() error when a concept that shouldn't even have been substituted attempts to perform a multi-dimensional array initialization with a new{} expression. Although fixing the requirements short-circuiting is probably too risky at this point, we can get closer to the intended effect by silencing that sorry just as we silence other errors. for gcc/cp/ChangeLog PR c++/71965 * init.c (build_vec_init): Silence error, former sorry, without tf_error. for gcc/testsuite/ChangeLog PR c++/71965 * g++.dg/concepts/pr71965.C: New. --- gcc/cp/init.c | 19 ++++++++++++------- gcc/testsuite/g++.dg/concepts/pr71965.C | 27 +++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 7 deletions(-) create mode 100644 gcc/testsuite/g++.dg/concepts/pr71965.C diff --git a/gcc/cp/init.c b/gcc/cp/init.c index 2263d12563cd..ff52c42c1ad8 100644 --- a/gcc/cp/init.c +++ b/gcc/cp/init.c @@ -4381,12 +4381,17 @@ build_vec_init (tree base, tree maxindex, tree init, else if (TREE_CODE (type) == ARRAY_TYPE) { if (init && !BRACE_ENCLOSED_INITIALIZER_P (init)) - sorry - ("cannot initialize multi-dimensional array with initializer"); - elt_init = build_vec_init (build1 (INDIRECT_REF, type, base), - 0, init, - explicit_value_init_p, - 0, complain); + { + if ((complain & tf_error)) + error_at (loc, "array must be initialized " + "with a brace-enclosed initializer"); + elt_init = error_mark_node; + } + else + elt_init = build_vec_init (build1 (INDIRECT_REF, type, base), + 0, init, + explicit_value_init_p, + 0, complain); } else if (explicit_value_init_p) { @@ -4446,7 +4451,7 @@ build_vec_init (tree base, tree maxindex, tree init, } current_stmt_tree ()->stmts_are_full_exprs_p = 1; - if (elt_init) + if (elt_init && !errors) finish_expr_stmt (elt_init); current_stmt_tree ()->stmts_are_full_exprs_p = 0; diff --git a/gcc/testsuite/g++.dg/concepts/pr71965.C b/gcc/testsuite/g++.dg/concepts/pr71965.C new file mode 100644 index 000000000000..6bfaef19211f --- /dev/null +++ b/gcc/testsuite/g++.dg/concepts/pr71965.C @@ -0,0 +1,27 @@ +// { dg-do compile { target c++14 } } +// { dg-options "-fconcepts" } + +template +concept bool Destructible() { + return false; +} + +template +concept bool ConstructibleObject = + // Concept evaluation should short-circuit even the template + // substitution, so we shouldn't even substitute into the requires + // constraint and the unimplemented multi-dimensional new T{...} + // initialization. ATM we do, but as long as we don't output the + // sorry() message we used to for such constructs when asked not + // to issue errors, this shouldn't be a problem for this and + // similar cases. + Destructible() && requires (Args&&...args) { + new T{ (Args&&)args... }; + }; + +int main() { + using T = int[2][2]; + // GCC has not implemented initialization of multi-dimensional + // arrays with new{} expressions. + static_assert(!ConstructibleObject); +} -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer