We add the `dart.tool.dart2wasm.minify` environment define (analogous to
how dart2js exposes `dart.tool.dart2js.minify`).
We make `package:expect/variations.dart` then expose to tests what
guarantees they can assume, namely
* `readableTypeStrings`
* `preciseErrorsWithDetails`
Change-Id: I43da09ed924ca9137721f4d70b7a494e01bf36e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430680
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When a cascade section contains a null-aware expression, the null
shorting should be terminated at the end of the cascade section. For
example, in the statement:
e..x?.f()..g();
if `e.x` evaluates to `null`, the call to `f()` should be skipped, but
not the call to `g()`.
Prior to this fix, the analyzer erroneously considered the null
shorting to be terminated at the end of the entire cascade. The
mistake wasn't easily observed, since the analyzer doesn't have
back-end semantics. But it was still observable in some rare cases
involving type promotion. For example, in the statement:
e..x?.f(i!)..g(i!);
the analyzer would consider the second `!` to be unnecessary, because
in its model of flow control, `g(i!)` would only ever execute after
`f(i!)`.
Fixes https://github.com/dart-lang/sdk/issues/59658.
Bug: https://github.com/dart-lang/sdk/issues/59658
Change-Id: I8540daca121dac6960f8d6a2a3ffa3e38a0bf921
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398926
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I'm currently working on some refactoring of flow analysis, and I
discovered through a trybot failure that I accidentally broke the
handling of null shorting inside conditional expressions. The trybot
failure was subtle and confusing, though; in order to diagnose it I
had to do a lot of work to reduce it to a straightforward test
case. This CL adds the straightforward test case as a language test,
so that in case the problem recurs, it will be easier to diagnose.
Change-Id: I8a035221d0c9fff3bd0e0cbb8e3b5809b6793726
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398000
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The new formatter supports opting a region of code out from being
formatted. I'm applying this marker to all of the multitests since
those tests are often very sensitive to formatting and easily broken.
This way, anyone touching a multitest (including me when I reformat
the tests) doesn't have to remember to not run the formatter on it.
Unfortunately, this doesn't opt out 100# of the multitests. There are a
handful of multitests that also contain "@dart=" comments and are thus
formatted using the old style where the "// dart format off" marker has
no effect. For those, we'll have to still be careful to not accidentally
format them.
Change-Id: I257d0ee1eb44eee57047be06b8520f0ccc7b56d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396162
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
When these tests were written
(https://dart-review.googlesource.com/c/sdk/+/178880), Dart did not
support field promotion. I was getting ready to add "why not promoted"
logic to flow analysis so that if a user tried and failed to promote a
field, and received an assignability error as a result, they would
receive a helpful error message explaining that field promotion was
not supported.
In order to generate this error message, flow analysis would have to
start keeping track of some *counterfactual* promoted types,
indicating what the type of certain expressions *would have been* if
field promotion had been supported. It was important to make sure that
these counterfactual promoted types were only used for error message
generation, and didn't actually change Dart semantics. So I wrote
these tests to help lock down the existing (non-promotion) behavior.
When field promotion was actually implemented in Dart 3.2, these tests
should have been given `@dart=3.1` annotations, since their purpose
was to validate the correct behavior of the implementation in
situations where field promotion *wasn't* enabled. I should have been
prompted to do this by a test failure, because when I enabled field
promotion by default in Dart 3.2, the behavior of the tests should
have changed. However, because of
https://github.com/dart-lang/language/issues/4127, the behavior didn't
change, so I didn't notice that these tests needed updating.
Now, I'm getting ready to fix
https://github.com/dart-lang/language/issues/4127, so in order to
prepare for that, I need to give these tests the proper `@dart=3.1`
annotations.
Bug: https://github.com/dart-lang/language/issues/4127
Change-Id: I59ad1eef7b01ccedcc8fb99e070a05273ac365e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389781
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Collects files from `package:async_helper` and `tests/language`
that are generally useful, so that all test-related helpers are
in `package:expect`.
Moves the two libraries from `package:async_helper` into `package:expect`,
and the `tests/language/static_type_helper.dart` file too.
Deprecates `async_minitest.dart`, to follow `minitest.dart`,
expecting the Flutter use of it to have been fixed to not break
on deprecation (I believe Flutter no longer breaks builds on deprecations at all).
Patch 1 is the actual change.
Patch 2+4+8 is changing all existing references to the files.
Patch 6 ignores deprecation in files still using `async_minitest.dart`.
3+5+7+9 are updating this text to make the numbers match.
Then it's just test-expectations and small tweaks from there.
Change-Id: I1b665135b5fef9b9a0c3b340ffe9daf874d0174c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373120
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This CL changes the specification parser grammar to support a switch
expression that has zero cases (this is a missing update, the feature
specification already has it). It also changes several language tests
such that they expect a 'syntax error' rather than a 'compile-time
error'. This makes no difference for any tool except the specification
parser, for which it is needed (in general, a test that is expected
to have a compile-time error will parse just fine, so we need a
separate test outcome expectation for syntax errors).
Change-Id: Ifa00c11ce6c57053bd490e11a41d6e8d7b82a2d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384600
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This change reverts https://dart-review.googlesource.com/c/sdk/+/341020.
The reverted CL removed tests from `tests/language` that contained
legacy code (code with a language version less than 2.12). The primary
purpose of the removal was to unblock removal of legacy support from
the analyzer. It seemed safe to do because legacy code isn't supported
anymore, and no legacy code exists in google3 anymore. However,
several of those tests exercised important "weak mode" runtime
semantics of the web and VM platforms. See discussion at
https://dart-review.googlesource.com/c/sdk/+/341020/comments/bce31aa1_f5392ce1
for details.
This CL restores the deleted tests. Fortunately, since all the
restored tests are annotated with `Requirements=nnbd-weak`, they will
be skipped on the analyzer (thanks to
https://dart-review.googlesource.com/c/sdk/+/342080), so restoring
them no longer gets in the way of removing legacy support from the
analyzer.
Change-Id: Ib828be76f5c7eaeecaad0b7e7f7b0e3ff2f4bdb2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342090
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The annotation `Requirements=nnbd-weak` controls prevents a test from
being run on a platform that doesn't have weak mode runtime semantics
(e.g. a program running with sound null safety).
In a previous CL
(https://dart-review.googlesource.com/c/sdk/+/341020), I removed
several tests from `tests/language` that contained legacy code, in
order to unblock removal of legacy support from the analyzer; those
tests all contained this annotation. However, after discussion with
Siggi, we've decided that it would be better to keep those tests
around for a while longer, because they exercise important runtime
behaviors of unsound null safety mode on the web and VM platforms, and
not all google3 code has been migrated off of unsound null safety mode
yet.
So, I intend to take a different approach to unblocking removal of
legacy support from the analyzer: stop running tests with the
annotation `Requirements=nnbd-weak` through the analyzer. This will
allow the tests removed in
https://dart-review.googlesource.com/c/sdk/+/341020 to be restored,
but it will have a side effect of causing a small number of additional
analyzer tests to be skipped. All those tests are benign to skip on
the analyzer (because they are purely concerned with runtime
semantics) except for one:
`superinterfaces_out_of_order_error_test.dart`.
This test doesn't have any runtime semantics at all; it merely checks
that the analyzer and CFE produce the correct errors for certain
compile-time type checks that have nothing to do with weak mode
runtime semantics.
So, to prevent a gap in test coverage when the analyzer begins
skipping tests annotated with `Requirements=nnbd-weak`, we need to
remove this annotation from
`superinterfaces_out_of_order_error_test.dart`.
Change-Id: I7932a0200be750116c41a303b48aaef50bc952ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341980
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that we no longer need to support legacy (pre-2.12) code in
google3, we don't need to test our support for it either.
Most of our language tests for legacy code were in `tests/language_2`
and have already been deleted; this CL addresses the few tests that
remain in `tests/language`, mostly dealing with "mixed mode" scenarios
(i.e., interactions between legacy code and null safe code).
Change-Id: I023d84547fdf17fb0599c82fbeb4fd07252ccf0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341020
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The tests `variable_property_not_promoted_test` and
`this_property_not_promoted_test` verify that fields are _not_
promoted. To prevent them from failing when we enable the language
feature `inference-update-2` (which provides field promotion), they
need `@dart=3.0` directives. This ensures that we will continue to
have coverage of the old (non-promoting) behavior after field
promotion is switched on.
Bug: https://github.com/dart-lang/language/issues/2020
Change-Id: I376da01dfe4223f17ae4863e4460b4f1a0708dc6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314760
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Test tests/language/nnbd/syntax/opt_out_nnbd_modifiers_test.dart
has a legacy library, so it cannot run with sound null safety.
This change adds '// Requirements=nnbd-weak' in order to skip
this test in sound null safe mode.
Change-Id: I48eb0d920a1de8e426aa9663ce8338b92e73c9aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304207
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Mark tests that contain errors about using a class as a mixin to use
language version 2.19 where that's not an error.
This may not fix all of the tests because it's the language version of
the library where the class is declared that matters, not where the
class is used as a mixin. But most tests have all of their declarations
in the same library, so this should fix most.
Change-Id: I910439ebd2f10f731418dc588b7e4619a0841c16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285923
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Overriding fields can change the type to remove nullability and
can also be final so they override the getters only.
For DDC that means there is an inherited setter that could still be nullable and a forwarding setter that should allow null even though
the type of the overriding field is non-nullable. With enhanced null
safety asserts enabled in weak mode there should be no failure when
setting the inherited field to null.
Fixes: https://github.com/dart-lang/sdk/issues/50569
Change-Id: Ie6af0d1e265a5f3b15469311fa1f7e2a184d95ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/272480
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Several unusual constructs that lead to unreachable code are now
recognized by flow analysis:
- Control flow after an expression of the form `e ?? other` or `e ??=
other`, where `e` has static type `Null` and `other` has static type
`Never`, is considered unreachable.
- Control flow predicated on an expression of the form `e is Never`
evaluating to `true` is considered unreachable.
- Control flow predicated on an expression of the form `e is! Never`
evaluating to `false` is considered unreachable.
- Control flow on the RHS of a null-aware access such as
`e?.property...`, `e?.property = ...` or `e?.method(...)`, where `e`
has static type `Null`, is considered unreachable (Note: this can
arise in the presence of extension methods).
Previously, these behaviors only took effect if `e` was a reference to
a local variable.
Note: the change to `regress/issue_31180` is because I’ve corrected
the behavior of implicit temporary variables to not undergo a type
change from `Null` to `dynamic`, so the dead code part of `null?[1]`
is now erroneous. (I had to make this change in order for the last
bullet above to work properly; without it, the type change to
`dynamic` prevents flow analysis from recognizing that the code to the
right of `?.` is unreachable.) There's no behavioral change to
correct code, but I've captured the behavioral change to incorrect
code in
`tests/language_2/null_aware/null_aware_index_on_null_error_test.dart`.
Bug: https://github.com/dart-lang/sdk/issues/49635
Change-Id: I8b24b3b040a34f897c0b61dcb9bd105be6d0af6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This reverts commit 0f3dea33f9.
Reason for revert: breaks dart->engine roller as flutter still uses NullThrownError, fails analysis step
Original change's description:
> Deprecate outdated errors, drop `CastError` and `NullThrownError`.
>
> Both `CastError` and `NullThrownError` becomes just (deprecated) aliases for `TypeError`.
>
> `FallThroughError` becomes deprecated. Fall-through was made a compile-time error in Dart 2.0, the error should no longer be used.
>
> `CyclicInitializationError` is deprecated. Null safe Dart doesn't specify which error a late initialization error throws. We use internal errors now.
>
> These errors should not be needed in sound null-safe mode (if they are even needed now), and so should be removed in Dart 3.0.
>
> TEST= No new tests, should not change behavior in a significant way.
>
> Bug: https://github.com/dart-lang/sdk/issues/49141
> Change-Id: I636e9a0d0c32021d40bb819a88a1f57db6efc5a9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247384
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Reviewed-by: Brian Quinlan <bquinlan@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: https://github.com/dart-lang/sdk/issues/49141
Change-Id: I1b2802ec69fe654525e683527ff3554ff972f0c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248741
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Both `CastError` and `NullThrownError` becomes just (deprecated) aliases for `TypeError`.
`FallThroughError` becomes deprecated. Fall-through was made a compile-time error in Dart 2.0, the error should no longer be used.
`CyclicInitializationError` is deprecated. Null safe Dart doesn't specify which error a late initialization error throws. We use internal errors now.
These errors should not be needed in sound null-safe mode (if they are even needed now), and so should be removed in Dart 3.0.
TEST= No new tests, should not change behavior in a significant way.
Bug: https://github.com/dart-lang/sdk/issues/49141
Change-Id: I636e9a0d0c32021d40bb819a88a1f57db6efc5a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247384
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Martin Kustermann