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>
This CL changes `late x;` to `late var x;` in a test. Apparently, this
syntax was considered correct and the front end and analyzer accept it.
However, it is a syntax error, and this CL corrects it. The fact that
the tools accept it is reported as SDK issue #43811.
Change-Id: Iaa2fe56fe99d3702345368a54a7389a59288515c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/167804
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Demoting a variable back to its declared type discards types of
interest, therefore in order to verify that a type is of interest, we
need to join a demoting path with a non-demoting path so that the type
of interest is preserved.
Change-Id: Ie9c3278936b189120c9f0085f1563ff8062e51db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/164800
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These test cases cover the following scenarios:
- `is` and `is!` tests that do not appear inside an "if" statement.
- `== null` and `!= null` tests that do not appear inside an "if"
statement.
- `??=` assignment where the "write" type is nullable but the "read"
type is non-nullable (to make sure the implementation is using the
read type to decide whether to insert the null check).
- `??=` assignment where the LHS is a super call to the index operator.
- `??=` assignment where the LHS is accessed through an extension
(either explicitly or implicitly).
- `??=` assignment where the LHS is a null-aware indexed operator.
- Null-aware access to a getter.
- Null-aware access via a cascade.
- Null-aware access to a method/getter on Object (e.g. `toString()`).
- Null-aware access to a method/getter supplied by an extension that
extends a nullable type (either explicitly or implicitly).
Change-Id: I46aeb6ffc35fc776f48bcd838ff8e4acf7b39f05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162629
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Postfix increments and decrements are null-shorting expressions
(e.g. `x?.y++.isEven` only calls `isEven` if `x` was non-null), but it
is still being decided whether postfix `!` should be null shorting
(i.e. whether `x?.y!` should fail if `x` is null). See
https://github.com/dart-lang/language/issues/1163.
Previously, the analyzer was inconsistent about whether it considered
`!` to participate in null shorting; as a result, when analyzing an
expression like `x?.y!`, the analyzer would fail to call
`FlowAnalysis.nullAwareAccess_end`, resulting in corrupted flow
analysis state, which could lead to a crash.
This change makes the analyzer treat `!` as *not* participating in
null shorting, which is consistent with what is currently written in
the spec and implemented in the CFE.
Fixes#43093.
Change-Id: Ie69c5c29f226fe1a0282d0e7a1e079778dc700c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159147
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL performs the following checks in the invoke field dispatcher for
dynamic closure calls when lazy dispatchers are enabled:
* The provided function type arguments vector (if any) has the correct
length.
* No function type arguments should be provided if the closure has
delayed type arguments.
* All required arguments (positional in all modes, named in appropriate
null safety modes) have been provided by the caller.
* If there are optional positional arguments, an appropriate number
has been provided.
* If there are optional named arguments, their names are valid.
Since the runtime already handles checking the argument shapes when lazy
dispatchers are disabled, these checks are now completely removed from
closure bodies in all cases. Thus, the only remaining checks in closure
bodies are the type checks performed by AssertSubtype and
AssertAssignable when lazy dispatchers are enabled.
Changes in the Flutter Gallery:
* ARM7, release: -3.61% instructions, -2.19% total
* ARM7, sizeopt: -3.62% instructions, -2.55% total
* ARM8, release: -3.66% instructions, -1.98% total
* ARM8, sizeopt: -3.65% instructions, -2.37% total
Most of these changes are already exercised by existing tests such as
(but not limited to):
* corelib{,_2}/dynamic_nosuchmethod_test
* language{,_2}/call/call_test
* language{,_2}/closure/tearoff_dynamic_test
* language{,_2}/generic/function_bounds_test
* language{,_2}/parameter/named_with_conversions_test
* language{,_2}/vm/no_such_args_error_message_vm_test
I've added one test to specifically check the interaction between
dynamic calls and required named parameters. There is some coverage in
other NNBD tests, but those are not directly focused on testing this
specifically.
Other changes:
* Adds initial cached ranges for certain BinarySmiOp and ShiftIntegerOp
instructions when the RHS is a constant, to avoid false negatives for
deoptimization and throw checks prior to range analysis.
* Adds new slots for various Function fields.
* Adds the ability to define unboxed native slots, which are always
unboxed after retrieval even in unoptimized code. In the first
iteration, the backend only handles loads from Uint32 unboxed native
slots. Part of https://github.com/dart-lang/sdk/issues/42793.
* Removed the special handling for loading from non-nullable int fields
in AOT compilation. Instead, their treatment is unified with the
treatment of the new unboxed native fields, since the source field is
always unboxed and the result of the load is also always unboxed, as
code involving them is always optimized.
Bug: https://github.com/dart-lang/sdk/issues/40813
Change-Id: Ia02aa3e872c1fefd906fd67b55021ea1797556e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155604
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The new logic classifies the LHS and RHS of the equality check as
either null, non-nullable, or potentially nullable, and then either
promotes, treats the expression as equivalent to a boolean, or does
nothing, as appropriate.
This means, for example, that a comparison between a non-nullable
value and `null` is now known to evaluate to `true` for reachability
analysis.
Note: as part of this change, it was tempting to trigger promotion
whenever a varialbe is equality compared to an expression of type
`Null`, but this would be unsound (consider `(int? x) => x == (x =
null) ? true : x.isEven`). So we still only promote when the variable
is compared to a literal `null`.
Fixes#41985.
There's a corresponding spec change out for review:
https://github.com/dart-lang/language/pull/1134
Change-Id: Id7f1d4eaa3b0fa57124445bb8352eef32c304feb
Bug: https://github.com/dart-lang/sdk/issues/41985
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155926
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, we considered an expression unreachable if its type was
exactly `Never`. This CL switches to using TypeSystem.isBottom, which
correctly handles types like `T extends Never`.
Change-Id: Ia6ce580caab6bc7ce7cceb1d0097b50f1da88f8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154746
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The bootstrapping was still loading the wrong version of the sdk and
pre-compiled packages when running tests for DDC.
Update constant_null_safety_mode_test to test a constant that is
defined within the sdk itself in addition to one defined in the test.
Change-Id: I8938ed92d866cfca0ce42567f03bed5f3dd9f10c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154121
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Mayank Patke