This CL adds a new --interop-null-assertions flag (cf.
--native-null-assertions) with the goal of validating that JS interop
APIs with non-nullable static return types do not return null values.
This flag is currently disabled by default but is intended to assist in
sound null safety migrations.
In general, we don't guarantee type soundness of package:js interop
since users can write incorrect static types which are not backed by
any runtime checks. However, it is likely that during the null safety
migration, some interop APIs which should have been made nullable
weren't. Therefore, we want to offer some additional (but limited)
checking for this case.
For static invocations of functions with non-nullable return types, we
can simply perform a null check on the result of the call.
For instance methods (which could be invoked virtually/dynamically), we
want to perform a null check on the return value in the callee (the
interceptor method) itself when possible.
It's possible for multiple interop bindings to share the same
interceptor method. We produce a null check in the interceptor method
body if all the methods have non-nullable return types. Otherwise, we
insert checks at callsites when appropriate.
Change-Id: Ifd155d7f8326152b6d57d61199e0b7973c4a1211
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369784
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
This CL moves native assets resolution to the embedder.
The Dart VM looks up the asset path (for example
`['relative', 'foo.so']`) with the asset id. The embedder defines
callbacks for asset loading, and returns a handle to the dylib.
Then the VM calls the embedder again with `dlsym` to lookup the symbol.
The Dart VM & kernel compiler are responsible for the asset id to
asset path mapping. The kernel compiler compiles it into the snapshot
and the VM looks it up in the snapshot.
Relative paths are resolved relative to the isolate script uri (kernel
snapshot, jit snapshot, aot snapshot, or `dart compile exe` result).
The embedder is responsible for remembering the script uri it set when
spawning the isolate group.
This CL does not add `dlclose` or `dladdr` embedder callbacks yet.
Bug: https://github.com/dart-lang/sdk/issues/55521
Bug: https://github.com/dart-lang/sdk/issues/55966
TEST=pkg/dartdev/test/native_assets/build_test.dart
TEST=tests/ffi/native_assets/asset_relative_test.dart
Bug: https://github.com/dart-lang/sdk/issues/55410
Bug: https://github.com/dart-lang/sdk/issues/55523
Bug: https://github.com/dart-lang/sdk/issues/55207
Change-Id: I75ec4a368c5fb3d2f76b03771e796ff56bcac941
Cq-Include-Trybots: dart/try:vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,vm-aot-win-debug-x64c-try,pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-mac-release-try,pkg-mac-release-arm64-try,pkg-win-release-try,pkg-win-release-arm64-try,vm-aot-asan-linux-release-x64-try,vm-asan-linux-release-x64-try,vm-aot-msan-linux-release-x64-try,vm-msan-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/361881
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Make tool (by default) give error when test entry specified in status
file does not exist. Make -w (by default) remove such entries.
Cleanup most status files, fixing a few entries containing `.dart` and
removing obsolete entries (i.e. entries pointing to nonexisting tests).
This should for instance have given an error in
https://dart-review.googlesource.com/c/sdk/+/370600 saying that the file
I specified didn't exist (in that I shouldn't have specified the `.dart`
part).
TEST=No tests, this is status file maintenance.
Change-Id: Ie977bf15dea2e3dad8d771fd3e99917317e975f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370886
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This is a reland of commit 35bc17a0fa
Changes from the original CL is that we now allow packages in
`allowedInteropLibrariesInDart2WasmPackages`.
Original change's description:
> [dart2wasm] Check import/export pragmas in user code
>
> Change-Id: I926d108a4571d685c67d3a174a8e506910cce8f7
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369020
> Commit-Queue: Ömer Ağacan <omersa@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: I69f61ecf246dfdbfcab372c6c2adb2a64f2d0b36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370900
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This is a follow-up to [0]. That CL changed dart2wasm's modular
transformer to issue an error if `dart:ffi` is imported.
Users of packages that have specialized code for the VM (which supports
FFI) use conditional imports based on `dart.library.ffi`. We don't want
the VM-specific code to be used for web in dart2wasm (as dart2wasm
doesn't support the entirety of `dart:ffi`).
As a result we're going to make `dart.library.ffi` be false in
coditional imports (as well as in
`const bool.fromEnvironment('dart.library.ffi')`).
[0] https://dart-review.googlesource.com/c/sdk/+/368568
Issue https://github.com/dart-lang/sdk/issues/55948
Issue https://github.com/flutter/flutter/issues/149984
Change-Id: I70a775278ab701d1fd2596521e378cb6364edac2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370580
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Followup to fb057ea4e0
Now that the web implementation of DateTime supports microseconds, the test special cases for not supporting microseconds can be removed.
Change-Id: I10991b25e42d643ae58850d7190621c9d11877b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367680
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Previously, if a record literal had named fields, type inference of
the literal fields would happen as part of the process of
hoisting. This was a problem because the hoisting process requires
visiting the fields in reverse order, so as a result, the order in
which subexpressions were type inferred was the reverse of the order
in which they would be executed, leading to unsound type promotion
behavior.
Fixes#55914.
Bug: https://github.com/dart-lang/sdk/issues/55914
Change-Id: I2d8930e0e1d7579d065bfb850aa7472d28a8012c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369761
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
No client of the VM uses this flag, only tests, and this flag was always
set to false in AOT mode. Thus, remove uses of this flag and instead
always lazily create dispatchers as needed when resolving method names
in JIT mode.
Remove the implicit value of `allow_add` for some Resolver
static methods. For callers that previously depended on the implicit
`true` value (which includes the AOT precompilier), pass `true` for
uses in the compiler and pass `!FLAG_precompiled_mode` for uses in the
runtime. Assert that `allow_add` is false when these methods are invoked
from the precompiled runtime.
Remove Resolver static methods that are no longer used.
TEST=ci
Change-Id: Ib6a7354f7a859e86743c381513a4129c14895753
Cq-Include-Trybots: luci.dart.try:vm-linux-debug-x64-try,vm-linux-release-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try,vm-mac-debug-arm64-try,vm-mac-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366668
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
If HttpResponse is being closed prematurally (e.g. because client
decided to close its request) we need to propagate cancellation
to the stream which is being piped into the response. Otherwise
we will keep that stream forever hanging around and leak underlying
resources.
Fixes https://github.com/dart-lang/sdk/issues/55886
TEST=tests/standalone/io/regress_55886_test.dart
R=kustermann@google.com
Change-Id: I7c294ed19cc7c350fd101b078bd650ce8a6526a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/369061
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Original change: https://dart-review.googlesource.com/c/sdk/+/366963
This reverts commit 72b2883c6f.
[js_runtime, js_dev_runtime] Implement `microsecond` field of `DataTime`
- Move DateTime implementation for dart2js and DDC into a shared place to reduce duplication.
- Add a _microsecond field to the web DateTime to track microseconds outside of the JavaScript Date.
- The cute dart2js optimization whereby `DateTime.now().millisecondsSinceEpoch` is compiled to `Date.now()` still works.
- Both implementations report better errors.
- Fixed VM bug with in-range sentinel.
Issue: https://github.com/dart-lang/sdk/issues/44876
Issue: https://github.com/firebase/flutterfire/issues/12102
Issue: b/342552853
CoreLibraryReviewExempt: Reapply of unchanged code
Change-Id: I7f14b69e412a052ef3fe6b43cc9cf9d96319adb8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368380
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Delay changing Thread::vm_tag on callback entry and restore the tag early on callback return so that the profiler doesn't see the "running Dart" tag unless it can also see the fake return address marking the entry frame.
TEST=ffi/async_void_function_callbacks, ffi/function_callbacks_subtype, ffi/function_callbacks, ffi/isolate_local_function_callbacks
Bug: https://github.com/dart-lang/sdk/issues/52814
Change-Id: I40d80ec7c44063d078db0e211565e2d127c6b81e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367460
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Equal types should have the same hash, but they are not necessarily
identical.
Update the test to remove the identity check between a constant type and
a type constructed in runtime.
Change-Id: I0d6c6395c587391d3087c26b00fff36d645b33dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368340
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
We have an optimization that will do list lookups at compile time when
the receiver is a constant list and the index is a constant integer.
=> We should only perform this optimization if index is in-bounds.
=> If it's out-of-bounds it should be a [RangeError] thrown at runtime
(if that code is ever executed)
Closes https://github.com/dart-lang/sdk/issues/55817
Change-Id: I3e99cdd96c79e7ff3f490babb2d52131cbd83a88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368302
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This reverts commit fb057ea4e0.
Reason for revert: b/342552853
Original change's description:
> [js_runtime, js_dev_runtime] Implement `microsecond` field of `DataTime`
>
> - Move DateTime implementation for dart2js and DDC into a shared place to reduce duplication.
>
> - Add a _microsecond field to the web DateTime to track microseconds outside of the JavaScript Date.
>
> - The cute dart2js optimization whereby `DateTime.now().millisecondsSinceEpoch` is compiled to `Date.now()` still works.
>
> - Both implementations report better errors.
>
> - Fixed VM bug with in-range sentinel.
>
>
> Change-Id: I9156255bdb6ecc195500ae9bc88f91fb315b6297
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366963
> Reviewed-by: Alexander Aprelev <aam@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Stephen Adams <sra@google.com>
Change-Id: I58572256a7710df4589bb5e41c7afee295c2388b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368103
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Fix follow up comments with an async rethrow test.
Tests that wildcard patterns still work while mixed with wildcard variables.
Bug: https://github.com/dart-lang/sdk/issues/55652
Change-Id: If6ab4de68ff27ad51215427a7183f1aed7229947
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367501
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Knowing whether Dart code is running in a WebAssembly context is useful
to potentially select different code paths exploiting differences in
JavaScript and WASM behavior or simply to report the information to
users (e.g. for crash reports).
Without such a constant, one has to rely on implementation differences
such as `identical(0, 0.0)` or check the available `dart:` libraries.
Both are error-prone, so having a reliable constant as an alternative
makes this easier.
Closes https://github.com/dart-lang/sdk/issues/55694
Change-Id: Ia969641e4b78223c394cbf251805cf77a30cb0fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365822
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
I convert the `noSuchMethod` tests to (imho) simpler tests of what
property access of `e` or `d` or `D` would look like on an int, via
extension getters.
The noSuchMethod test as it was written cannot be executed at runtime,
because (as of Dart 2, I think, maybe earlier), property access on
expressions is a compile-time consideration. And I think as a compile-
time error test, it's hard to see what it's testing.
Change-Id: I5c0ca728e6e812b8f35adb80b288be351c4b076a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367461
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
- Move DateTime implementation for dart2js and DDC into a shared place to reduce duplication.
- Add a _microsecond field to the web DateTime to track microseconds outside of the JavaScript Date.
- The cute dart2js optimization whereby `DateTime.now().millisecondsSinceEpoch` is compiled to `Date.now()` still works.
- Both implementations report better errors.
- Fixed VM bug with in-range sentinel.
Change-Id: I9156255bdb6ecc195500ae9bc88f91fb315b6297
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366963
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Added a little section for late wildcard variables too.
This CL tests mixing top-level wildcard declarations with local wildcard declarations and the non-shadowing, non-binding behaviour.
Bug: https://github.com/dart-lang/sdk/issues/55652
Change-Id: I72e7cfb1b2d80a3934af355579c36252881cf3fb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367241
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Making language tests in small batches. These are very basic ones to test that you can have multiple local declarations named `_` in the same namespace without a collision error.
Bug: https://github.com/dart-lang/sdk/issues/55652
Change-Id: I4d00e9072ba745b363d68db72505c599953c41ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366022
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This gives some more coverage for `dart compile wasm`
Change-Id: I62e7f9c6ecbdf80a1445c35d1733a7f89e6bcf54
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366623
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Note that this is not a breaking change, since the CFE already
correctly flags the error condition.
Fixes#55734.
Bug: https://github.com/dart-lang/sdk/issues/55734
Change-Id: I5570e0840ce20c2a761d88f698b9876f7543bd8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366680
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This never worked. It was silently accepted, at least if the future had no listeners, then any later attempt to use the future would cause a stack overflow or other impossible results.
Moves some `_Future._complete` call out of try-catch.
The `_complete` shouldn't throw (but before this fix it could).
Moving them out of the `try`/`catch` makes such errors be reported
as unhandled, instead of catching them and trying to complete the same
future again with an error, when it's possibly in an inconsistent state.
Fixes#43662.
Based on https://github.com/dart-lang/sdk/issues/43662#issuecomment-2058870247
CoreLibraryReviewExempt: No response.
Bug: http://dartbug.com/43662
Change-Id: I96a4f01bcd5b6cee93bba267299852569a9b905c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363060
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Currently the type of a static field is only based on the dart type, not
inferred types. This can mean that the type of such field is e.g.
`dynamic`.
Though the return type of the initializer function used the unboxing
information.
=> There was an invariant that if we use `null` to signal uninitialized
in the global, then calling the initializer will also result in a
non-nullable reference type.
=> This was invariant was broken by recent changes to dart2wasm that
take advantage of TFA-inferred unboxing information.
=> We fix this inconsistency by ensuring the wasm global's type is the
same as the initializer function's return type.
Change-Id: I9c27c0b28d2f81f888b4c9afc59dad42af2229ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365825
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The list factory specialization code can only know constant values
passed to `growable: <xxx>` if the variables are local and not
parameters.
TEST=corelib/list_factory_specialization_regression_test
Change-Id: I2c425108fd266fea6b443a7adee86c5a2b33a4d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365584
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The expriment is now retired in Dart 3.5, and the flag
stops being valid.
Change-Id: I1ecb087d45b90e98a7f0d3c15a6c8038a1c6982e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365260
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
For example code that uses `Completer` in parameters/fields/...
used to be represented as `Object` in wasm type system, which we
can now represent instead as `_Completer`.
Change-Id: I35b2d8cb45717e58a813756dfa6278804552fbcb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365020
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
When analyzing the type test implied by a pattern, flow analysis uses
three variables to control promotion behavior:
- `matchFailsIfWrongType`, which indicates whether flow analysis needs
to account for the possible control flow path resulting from the
type test failing. (This is `false` for cast patterns, because in
the case where a cast pattern fails, an exception is thrown).
- `matchMayFailEvenIfCorrectType`, which indicates whether flow
analysis needs to account for the possible control flow path
resulting from the type test succeeding, but some other check
causing the match to fail. (This is `true` for most list patterns,
because the list pattern will fail to match if the list has the
wrong length).
(Note that `matchMayFailEvenIfCorrectType` doesn't account for the
fact that a pattern match might fail due to failure in a subpattern
match; this is automatically handled by the fact that flow analysis
walks through the complete pattern in the order in which it
executes.)
- `coversMatchedType`, which indicates whether the type test is
guaranteed to succeed due to a subtype relationship between the
matched value type and the type being tested (e.g. a `num x` pattern
is guaranteed to succeed if the matched value type is `int`).
In the case where `matchFailsIfWrongType` is `true`,
`matchMayFailEvenIfCorrectType` is `true`, and `coversMatchedType` is
`false`, flow analysis must account for the fact that there are two
ways that the pattern match might fail: the type test might fail, or
the type test might succeed but then the pattern match might fail for
some other reason.
Before this change, this was done incorrectly, and flow analysis only
accounted for the possibility of the type test failing.
Fixes#55543.
Bug: https://github.com/dart-lang/sdk/issues/55543
Change-Id: I86603ec5f940402313f32177212b7960878db97f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364942
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>