[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.

From-SVN: r258749

gcc/cp/ChangeLog

@@ -1,5 +1,9 @@
 2018-03-21  Alexandre Oliva <aoliva@redhat.com>
 
+	PR c++/71965
+	* init.c (build_vec_init): Silence error, former sorry,
+	without tf_error.
+
 	PR c++/84610
 	PR c++/84642
 	* parser.c (abort_fully_implicit_template_p): New.

gcc/cp/init.c

@@ -4384,12 +4384,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");
+	      if ((complain & tf_error))
-	  elt_init = build_vec_init (build1 (INDIRECT_REF, type, base),
+		error_at (loc, "array must be initialized "
-				     0, init,
+			  "with a brace-enclosed initializer");
-				     explicit_value_init_p,
+	      elt_init = error_mark_node;
-				     0, complain);
+	    }
+	  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)
 	{
@@ -4449,7 +4454,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;
 

gcc/testsuite/ChangeLog

@@ -1,5 +1,8 @@
 2018-03-21  Alexandre Oliva <aoliva@redhat.com>
 
+	PR c++/71965
+	* g++.dg/concepts/pr71965.C: New.
+
 	PR c++/84610
 	PR c++/84642
 	* g++.dg/cpp0x/pr84610.C: New.

gcc/testsuite/g++.dg/concepts/pr71965.C

@@ -0,0 +1,27 @@
+// { dg-do compile { target c++14 } }
+// { dg-options "-fconcepts" }
+
+template <class T>
+concept bool Destructible() {
+    return false;
+}
+
+template <class T, class...Args>
+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<T>() && 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<T, T>);
+}