These tests acted as a guard to make sure we didn't unintentionally enable control flow and spread
in const collections when we initially shipped the features. Now that we are getting close to
enabling them for const they no longer valid.
Added a few more compile-time errors to the const spread error suite.
Change-Id: I52e215d4c1c4394f1a1b868c05241277b0d58d2a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/108680
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Returning since they should be valid with the `constant-update-2018` experiment
flag:
* control_flow_collections/if_const_test.dart
* control_flow_collections/if_const_error_test.dart
* spread_collections/const_test.dart
* spread_collections/const_error_test.dart
Should be deleted when UI-as-Code is supported in constant collections:
* control_flow_collections/if_const_syntax_error_test.dart
* spread_collections/const_syntax_error_test.dart
Change-Id: I595333782630122ae4f3d021841b062b27e1cccb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99600
Reviewed-by: Sigmund Cherem <sigmund@google.com>
* Update tests to expect compilation errors when `if` `for` or `...` are used in
const collections.
* Remove constant-update-2018 flag from tests.
Change-Id: I477c30f07c7e3da6139f263e1855c3908c1bce2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99485
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This helps triage/resolve various issues in testRuntimeErrors:
* for_non_bool_condition_test isolates the code causing a crash on the
dart2js-production-linux-d8 configuration. (See
https://github.com/dart-lang/sdk/issues/36442 and the status file.)
* for_null_condition_test will be an approved failure for all dart2js
configurations due to https://github.com/dart-lang/sdk/issues/36446.
* for_runtime_error_test contains all the remaining expected type
errors. On the dart2js-production-linux-d8 configuration (which runs
with -O3), we assume no type errors exist - even ones guarded by
Expect.throwsTypeError - so the optimized code produces runtime errors
instead. See https://dart-review.googlesource.com/c/sdk/+/97820 for a
similar discussion.
* for_test contains the remaining tests, which are valid on all dart2js
configurations.
Change-Id: Ifef4f7d2e27e2731cdd4a3fec03754ea63b6328d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98606
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This helps triage/resolve issues in testRuntimeErrors:
* if_null_condition_test will be an approved failure for all dart2js
configurations due to https://github.com/dart-lang/sdk/issues/34147.
* if_runtime_error_test contains all the expected type errors. On the
dart2js-production-linux-d8 configuration (which runs with -O3), we
assume no type errors exist - even ones guarded by
Expect.throwsTypeError - so the optimized code produces runtime errors
instead. See https://dart-review.googlesource.com/c/sdk/+/97820 for a
similar discussion.
Change-Id: Iaf2df85af16cc03fcd7ec7ef2a9e57a2bc3ce081
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98622
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
This lets you test that a callback returns a Future that completes to
a given error. Like Expect.throws(), but async.
At first, I added support for this directly to Expect.throws(), but I
think it's better to minimize the amount of dynamic logic going on in
the language test framework.
I was worried about having to duplicate all of the Expect.throws___()
convenience functions but now that we have generic methods, those
functions aren't that much more convenient.
Change-Id: I8b288945611fa16f8d27056f3cf79181fc22d256
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97881
Reviewed-by: William Hesse <whesse@google.com>
This doesn't cover all of the corner cases around the synthesized
stream subscription and stuff, but I honestly don't know if I'm
qualified to write those tests. This should cover all of the basic
static and runtime semantics that users care about.
Change-Id: I7237f0ccb9bf02af291d3175ab2c0074d0547c92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97548
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
The set-literals feature has shipped and is on be default. There is
no longer any need to pass it as an option to tests and the tools
cannot remove support for the flag while it is used in tests.
Change-Id: Ibf105ec01193ebb08d6e22600e6c7748897cc2ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96941
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
These don't try to comprehensively cover every interaction of async
and the new syntax, but they should test that an implementation handles
an await appearing in all the various places in the new syntax where an
expression is permitted.
Change-Id: I4852815002fcad6697f3bad4103693b1d4288d06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/94121
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Robert Nystrom