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

tests/language/assertion_initializer_const_error_test.dart

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

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

Typo: `2017`.

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

Done.

+// 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
+
+class C {
+  static bool check(x, y) => x < y;
+  final int x;
+  const C(this.x);
+  // The expression is not a potentially constant expression.
+  // This is a compile-time error.
+  const C.bc03(this.x, y) : assert(check(x, y));  //# 01: compile-time error
+}
+
+main() {
+  var c = new C(1);
+  // Ensure that the constructor is compiled.
+  c = new C.bc03(1, 2);  //# 01: continued

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

It's a tricky twist that (1) `new C.bc03` may not be compiled even though an
instance of `C` is created, so we have to include something like line 18, and
(2) using this `const` constructor in a `new` expression is sufficient to ensure
that the constructor is compiled, and hence that the checks on its initializers
are performed.

But I guess this subtle way to achieve the compile-time error is justified
because it tests another path in the tools than a plain `const C.bc03(1,2)`
would have done.

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

I moved the //#01 to the assert itself.

+  if (c.x != 1) throw "non-trivial use of c";
+}