Add assert-in-initializer-list to formal specification.

tests/language/assertion_initializer_const_function_error_test.dart

Index: tests/language/assertion_initializer_const_function_error_test.dart
diff --git a/tests/language/assertion_initializer_const_function_error_test.dart b/tests/language/assertion_initializer_const_function_error_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..638af0d44b343d717b633eba3bbf832c6a0363e1
--- /dev/null
+++ b/tests/language/assertion_initializer_const_function_error_test.dart
@@ -0,0 +1,26 @@
+// Copyright (c) 201, the Dart project authors.  Please see the AUTHORS file

[eernst, 2017/07/03 16:36:37]

Typo: `2017`.

+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+// VMOptions=--assert_initializer
+//
+// Dart test program testing assert statements.
+
+import "package:expect/expect.dart";
+
+class C {
+  static bool staticTrue() => true;
+  final int x;
+  const C(this.x);
+  // The expression *is* a compile-time constant, but not a bool value.
+  // Static warning, assertion throws which makes it a compile-time error.
+  const C.bc02(this.x, y) : assert(staticTrue); //# 01: static type warning

[eernst, 2017/07/03 16:36:37]

It's weird that we get a static type warning (at compile time, of course) at the
declaration of the constructor (cf. line 6793), and then (also at compile time)
an assertion error at each `const` invocation of the constructor (cf. line
6781). It is as if we had evaluated a user-defined correctness check and failed,
but we did in fact encounter an assertion which is mal-formed.

Maybe we should simply make it a compile-time error to have a function as an
argument to the assert in a const constructor initializer?

[eernst, 2017/07/04 09:09:20]

Next iteration: I'm no longer proposing that we make the declaration a
compile-time error: No changes requested here.

[Lasse Reichstein Nielsen, 2017/07/10 10:57:02]

The interesting thing is that a maltyped and failing assert statement is a
compile-time error in *checked* mode, but a static-warning in production mode.
We actually do have to handle both.
I think only status files can do that for us.

+}
+
+
+main() {
+  var c = const C(1);
+  // Assertion fails, so in checked mode it's a compile-time error.
+  // Production mode will succeed because the assertion isn't evaluated.

[eernst, 2017/07/03 16:36:37]

But then this test will fail by design in production mode (missing compile time
error). Maybe it should be marked as skipByDesign? (A related comment was added
below on the status file).

[Lasse Reichstein Nielsen, 2017/07/10 10:57:02]

It should be a "static type warning" in production mode. The analyzer should
detect that the type is wrong.

+  c = const C.bc02(1, 2);  //# 01: compile-time error
+  if (c.x != 1) throw "non-trivial use of c";
+}