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>
Some of these should be tests but were missing "_test". Others seemed
to simply be dead code. Some should have been referenced but there were
mistakes in the imports in other files.
Change-Id: If6f1d9e52a4babbf9883ddd437fc3091179f2ef2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/198141
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This changes the span reported from the _receiver_ to
the _use_ (method name, property name, operator token).
I think this change is overall an improvement.
Specifically, its a great improvement for cmdline
output, where the receiver and the "use" are on
different lines.
One possibly weird change is that if the operator is `[]`,
then I only highlight the `[` character. I don't know if
there is a better place, and I think this is fine.
Fixes https://github.com/dart-lang/sdk/issues/43708
Change-Id: Ie66ddf04b4904a367575193106385dd63ee39985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188680
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Since the flag is now enabled by default, there should be no mention of it.
There are still some uses in front_end/testcases that are not just removable
(it also uses `no-non-nullable`). There migth be more uses that are not
as easily found as grepping for `--enable-experiment
Removes two VM tests where fixing them meant they were just duplicating
the corresponding non *_2/ tests.
Fixes#44941
TEST= Large number of tests chaged.=(no-)?non-nullable`.
Change-Id: Ief755981ccde9a5482fcdf408c2929c74433a710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183688
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
I will soon be adding functionality to keep track of users' attempts
to promote things that aren't promotable (`this` as well as property
gets), so that we can give the user more useful error messages.
There's some some danger that adding this tracking logic will
accidentally cause side effects on reachability analysis. These tests
should help guard against unintentional behavioral changes.
Change-Id: I8dca901f2702ab7d309c6e12532aabfecd96a8ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178880
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
I will soon be adding functionality to keep track of users' attempts
to promote things that aren't promotable (`this` as well as property
gets), so that we can give the user more useful error messages.
There's some some danger that adding this tracking logic will
accidentally cause such expressions to be promoted. These tests
should help guard against unintentional behavioral changes.
Change-Id: I00d6c964c660602a3589a3efcf0042a11eaea5db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178882
Reviewed-by: Bob Nystrom <rnystrom@google.com>
As per planned breaking change to let platforms decide how they and what throw for late initiaization errors,
we no longer need a public `LateInitializationError` class. It's confusing to have one if some platforms throw
something else instead.
Removes the public abstract class. The dart:_internal implementation class `LateError` no longer implements it.
This is the only implementation of the public interface, and the class which platforms either throw directly,
or through front-end lowering of the feature.
Remove mentions in tests. All tests now just expect `Error`, some platform specific tests might test the message.
TEST=rewrote tests referring to LateInitializationError.
Change-Id: I54344a67f89ce101ed770412db134e12354cdcc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174928
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Use of PositionalCount() and PositionAt() as indices in the arguments
array must account for the type arguments if present. Otherwise, we'll
either skip checking the last positional argument (in the former case)
or check against the wrong arguments (in the latter case).
In nosuchmethod_forwarding_arguments_test.dart, add cases that check for
the above mistakes.
In require_named_args_strong_test.dart, use the more specific
throwsTypeError or throwsNoSuchMethod checks instead of the generic
throwsError to ensure the correct error is thrown.
TEST=Changed tests to add extra cases for failures that can happen.
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-nnbd-linux-debug-x64-try
Change-Id: If5e6c310d36d244bb0650ded54e32e583732584e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171947
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
In error reporting on assignability where the expression has type
`Null` we use a special messages that doesn't state that
"'Null' is nullable". Cases where `Null` is part of the type or where
the expression of type `Null` is derived from a collection are not
special cased.
Closes#43998Closes#44093
Change-Id: Ic0c79e6362f2365eb3fe8222ccd2ef8fac4f188d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170433
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Paul Berry