Additionally, fixed the template for html_dart2js so the generator would generate the correct code.
Change-Id: I2172bb10db413169b86690faa027365ff72e3d68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255763
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This adds support for the newly added `extern.externalize` and
`extern.internalize` instructions and uses these for converting to/from
`externref` instead of a JS round-trip.
Change-Id: If18d8f44ddf013d4c26bf1597be91bcd0db41c5a
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255462
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The API for the JS Promise integration API has changed to be part of
the `new WebAssembly.Function` constructor. This requires parameter
types to be specified explicitly. Apparently, these types currently
must be all `externref`.
Change-Id: Ifae634f65cfa377441be4b2dc0643c34b702fbe7
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255061
Reviewed-by: Stephen Adams <sra@google.com>
This splits the type hierarchy into three separate hierarchies with
the top types `any`, `func` and `extern`.
Update d8 to 10.6.91, which switches to the new type hierarchy.
Also, all ref shorthands for abstract heap types are now nullable, so
the type emitter in the `wasm_builder` is updated to follow that scheme.
To reduce confusion about the nullability of abstract reference types,
these now all require the nullability to be specified explicitly.
Change-Id: I4774d08cbed18307e481c466b2e3402a8d8fb6bd
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255060
Reviewed-by: Joshua Litt <joshualitt@google.com>
This implementation has a number of limitations:
- Returning a Future from an async function is not supported.
- Every async call switches to a new stack. A later optimization will
stay on the same stack if the call is directly awaited.
- Exceptions that cross async boundaries do not receive full stack
traces including the async suspension points. The stack trace of the
final exception just reflects the stack trace for the outermost
async call.
Change-Id: I2a5d5e30d6e955999ba55842c8b2ca3427cbf954
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241010
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Adds static method on `Isolate` to run an asynchronous function
in a separate isolate.
Change-Id: I673373fa02524f1d0b88099027cfaf1b796eb344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254960
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Statically type String variables to avoid dynamic calls for substring or concatenation.
Change-Id: If485243dc0580fd1f4e53ec4cf69cb3819a57b5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255301
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This reverts commit 4c7110332e.
Reason for revert: Still breaks the same tests, see b/242715525
Original change's description:
> Reapply "Avoid computing the URI scanner tables at runtime."
>
> This reverts commit 855e1cd975.
>
> The blocking issue in internal test code is assumed fixed.
>
> Change-Id: I74e0be130d149a45f77dc90c354916308b76b741
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255248
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Auto-Submit: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,kustermann@google.com
Change-Id: I391d2eb6dd9ae7367f656eaaaa7f9aeb1c31e0f7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255254
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Ilya Yanok <yanok@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This reverts commit 855e1cd975.
The blocking issue in internal test code is assumed fixed.
Change-Id: I74e0be130d149a45f77dc90c354916308b76b741
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255248
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Lasse Nielsen <lrn@google.com>
Builds on top of https://dart-review.googlesource.com/c/sdk/+/228660, introduces vm:vm:always-consider-inlining that tell inliner not to give up inlining of a function.
HashMap constructor got prefer-inline pragma to accommodate shift in inlining away from where it used to be inlined due to large size of inlined HashMap, greater than FLAG_inline_getters_setters_smaller_than heuristic.
Notable performance changes:
JIT (x64)
===
ListCopy.List.of.fixed.100 27.37%
ListCopy.List.of.fixed.2 16.31%
AOT (x64)
===
Empty -9.978%
InstantiateTypeArgs.Instantiate1 -8.262%
...
ListCopy.List.of.fixed.2 13.73%
ListCopy.spread.num.2 15.51%
ListCopy.List.of.2 15.08%
MapCopy.Map.String.of.Map.100 55.62%
MapCopy.Map.Thing.of.Map.100 56.06%
flutter release
===
flutter_gallery_apk_size (Pixel 2)
-0.0074% (1.0 noise)41809568.00 41812676.00
Addresses https://github.com/dart-lang/sdk/issues/49408
TEST=Inliner_always_consider_inlining, Inliner_List_of_inlined
Change-Id: I7f8fc7cb0ac4a69310c108cf519518c384dc0164
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253740
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Changes `FfiNative` instance methods on `NativeFieldWrapperClass`es
that have `Pointer<Void>` conversion to check for `nullptr`.
If the native field has `0`/`nullptr` a `StateError` is thrown:
"Bad state: Native field is nullptr."
This only makes sense if the first native field is used to point to
the C++ object corresponding to the Dart object. As far as we know
all current use cases do so.
TEST=pkg/vm/testcases/transformations/ffi/ffinative.dart.expect
TEST=tests/ffi/vmspecific_ffi_native_test.dart
Closes: https://github.com/dart-lang/sdk/issues/49620
Change-Id: I92f760c33d391476010722358f9713fa4491ab61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254200
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
The library wasn't taken into account when handling computing class
members in the K/J-model and not handled correctly when computing
applicable selectors. This made dart2js unable to handle members with
a name private to a different library than the enclosing library.
Fixes#33732Fixes#49226
Change-Id: I5ba143d87662bbd42e0ff02355054e4a937be8f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252665
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
These types now work with Dart_TypedDataAcquireData.
The presence of these types no longer degrades the performance of typed data indexed loads.
The presence of these types degrades the performance of typed data indexed stores much less. The performance of indexed stores is somewhat regressed if these types were not used.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/32028
Bug: https://github.com/dart-lang/sdk/issues/40924
Bug: https://github.com/dart-lang/sdk/issues/42785
Change-Id: I05ac5c9543f6f61ac37533b9efe511254778caed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253700
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
It appears that the environment was intended to be nullable in
some type constructions.
DDC running in weak mode can fail when null is passed as an argument
that is typed to be non-nullable.
Change-Id: I2c67efacc1166e6053ef8d8d7820de2c022c5e1b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253706
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Heap snapshots currently produced don't visit isolate stacks. As such
analyzing such snapshots may lead one to conclude there is a lot of
garbage while objects are actually reachable.
=> This CL makes us visit isolate stacks when building heap snapshots.
Furthermore we add a new `VMInternals.writeHeapSnapshotToFile` helper
that can be used to programmatically write snapshots and can be handy
for internal use at times. (We also use this helper in a test)
TEST=vm/dart{,_2}/heap_snapshot_test
Change-Id: I976544b7f6d20863764af9a40bf1ffb3c319bbce
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253785
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This was requested by internal teams for easier querying/processing.
Change-Id: I59fea565f79bf92d4cf808cc0466b4e9cfa37fe8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253707
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
The `registerElement` APIs in `dart:html` are legacy APIs based on a
deprecated Web Components v0.5 specification. These methods don't work
on modern browsers and can only be used with a polyfill.
The latest Web Components specification is supported indirectly via
JSInterop and doesn't have an explicit API in the `dart:html` library.
This change marks these APIs as deprecated. We intend to remove them in
the future (see https://github.com/dart-lang/sdk/issues/49536)
Fixes https://github.com/dart-lang/sdk/issues/48973
Change-Id: I2e96d36e95c9971b59cde80bc4da49b63d12b17c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252840
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Closes https://github.com/dart-lang/sdk/pull/49478
TEST=Manual
GitOrigin-RevId: f4c9c6869dfe73639295e86574a021523b3d374d
Change-Id: I134a97caed4eec59d70e9cbca16b7e9a472cf2c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251902
Reviewed-by: Michael Thomsen <mit@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Chisholm <kevinjchisholm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Move the method body out of one giant JS foreign function and into
Dart code with small JS foreign function calls inside.
The generous use of small JS foreign function calls ensures almost
identical compiled output with the exception of indentation, curly
braces on if statements, and single vs double quote differences.
Issue: https://github.com/dart-lang/sdk/issues/46002
Change-Id: Ice039fd096893e4f8869696ca46651b3d2e88add
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252410
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This is a reland of commit 08c13f173c
Fixes test failures on non-x64 architectures, both in the test
harness and due to DWARF5 line number program headers having a
non-backwards compatible format. (We generate DWARF2 in the
ELF snapshot writer, but the assembler used for assembly snapshots
may generate DWARF5.)
TEST=vm/dart{,_2}/use_dwarf_stack_traces_flag
Original change's description:
> [pkg/native_stack_traces] Support Mach-O dSYM debugging information.
>
> TEST=vm/dart{,_2}/use_dwarf_stack_traces_flag
>
> Bug: https://github.com/dart-lang/sdk/issues/43612
> Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-mac-product-x64-try,pkg-mac-release-arm64-try,vm-kernel-mac-release-arm64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try
> Change-Id: Icda21bb14dcc0cf4784cea118e6ba7dd4edd35aa
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250381
> Commit-Queue: Tess Strickland <sstrickl@google.com>
> Reviewed-by: Slava Egorov <vegorov@google.com>
Bug: https://github.com/dart-lang/sdk/issues/43612
Change-Id: I8a9cb70e78bc8594bcae004809c5a1be778d691d
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-mac-product-x64-try,pkg-mac-release-arm64-try,vm-kernel-mac-release-arm64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-nnbd-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-nnbd-mac-release-simarm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251464
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This fixes the breakage of barista3 introduced in
https://dart-review.googlesource.com/c/sdk/+/250480
Change-Id: I5ebca17ab35464e0c452d2fbe1b0f6574e05b6cd
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252381
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Auto-Submit: Aske Simon Christensen <askesc@google.com>
Move the method body out of one giant JS foreign function and into
Dart code with small JS foreign function calls inside.
Issue: https://github.com/dart-lang/sdk/issues/46002
Change-Id: I978f752c8bb6f09ed3c2ca7d149561f488034509
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251851
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Previously there was a window between the decision to resume generator
and actually running the micro-task. The stream could be canceled
during that window, making running the generator incorrect.
The solution is to check if the stream was canceled right before
resuming the generator in yield/yield*.
This change also unifies yield and yield* to check if the stream
was canceled even before suspending the generator.
TEST=language/async_star/cancel_while_paused_test,
language/async_star/cancel_while_paused_at_yield_test
Fixes https://github.com/dart-lang/sdk/issues/49451
Change-Id: Ib8ff3a2da9a6a7da8766a7dbf28e2c9d618728f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251562
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This change introduces separate stubs for suspending sync* functions
at start and at yield/yield*. Suspend stub for yield/yield*
no longer calls Dart callback (in order to make it faster).
Also, ReturnSyncStar stub is removed - sync* functions now directly
return false instead of going through the stub.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: Iee9a1f48cab2812cf0f9f0e4e6d8e847547e49f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250420
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This is a reland of commit bc8afad855
On top of the original commit, this change fixes incorrect
propagation of async/async*/sync* modifiers from a function to
its dynamic invocation forwarder.
TEST=ci, runtime/tests/vm/dart/regress_b_238653741_test.dart
Fixes b/238653741
Issue: https://github.com/dart-lang/sdk/issues/48378
Original change's description:
> [vm] Cleanup old async/async*/sync* implementation from the VM
>
> TEST=ci
>
> Issue: https://github.com/dart-lang/sdk/issues/48378
> Change-Id: I089ba4ed5613f30eec29f0db4ac6d5d8fbffd185
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249980
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
Change-Id: Iaad033d974a23fc6c5880a3d7f41818eb117f839
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251300
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Remove call to FATAL on a socket error event when we get back a null
error from the call to getsockopt with SO_ERROR, instead we just close
the socket.
(Should address the increased crash reports that apps are seeing after the FATAL call was added to see if we could get a stack trace when this condition happens).
TEST=ci
Change-Id: I39a399a7f60b218c665d30d6c43e7c18173c0e80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/250346
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
os_signposts needs explicit ids to match begin and end events, whereas all other trace systems do this implicitly.
TEST=Instruments
Bug: https://github.com/dart-lang/sdk/issues/49178
Change-Id: Ifeeaa1dfe823a0d5668f48b8c584f8bdeef23212
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249951
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
There is only one use of it in the SDK, `RuneIterator`,
one use of it outside, `TreeSet` from `package:quiver`,
and one known use in Google internal code.
There are other bi-directional iteration interfaces,
like `CharacterRange` from `package:characters`,
which can move a cursor in two directions,
but which didn't loke the `movePrevious` name and therefore
are not `BidirectionalIterator`s.
(There is also a Google internal class which mentions explicitly
why they're not `BidirectionalIterator`.)
There is no real need for this "shared" interface.
It doesn't carry its own weight.
We have no abstractions which work on the *interface*,
only code that works on one specific concrete implementation.
I'd recommend:
* `quiver` introduce a `TreeSetIterator` for their use-case
(the actual class has more public members than `BidirectionalIterator`,
which cannot be accessed through the declared type.)
* the Google internal code introduces its own interface
(which is just `Iterable` + `movePrevious`.
* The SDK will just make `RuneIterator` not implement
`BidirectionalIterator` at some (breaking) point.
Maybe just when we remove the type.
FLUTTER: Needs to land https://github.com/flutter/flutter/pull/106471 before merging this CL into Flutter.
Change-Id: Iaaa6b0c428d30eb3b68898c077d265ac0a622805
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249486
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit c97f7b7fad.
Reason for revert: Still breaking google3 (b/236665701)
Original change's description:
> Make `nullFuture` be per-zone.
>
> We introduced a `nullFuture` during the null-safety migration where
> we changed some methods to no longer allow returning `null`,
> and they therefore had to return a `Future`.
> That affected timing, because returning `null` was processed
> synchronously, and that change in timing made some tests fail.
> Rather that fix the fragile tests, we made the function return
> a recognizable future, a canonical `Future<Null>.value(null)`,
> and then recognized it and took a synchronous path for it.
>
> That caused other issues, because the future was created in the
> root zone. (Well, originally, it was created in the first zone
> which needed one, that was worse. Now it's created in the root zone.)
> Some code tries to contain asynchrony inside a custom zone, and
> then the get a `nullFuture` and calls `then` on it, and that
> schedules a microtask in the root zone.
> (It should probably have used the listener's zone, and not store
> a zone in the future at all, but that's how it was first done,
> and now people rely on that behavior too.)
>
> This change creates a `null` future *per zone* (lazily initialized
> when asked for). That should be sufficient because the code recognizing
> a returned `null` future is generally running in the same zone,
> but if any other code gets the `nullFuture`, it will be in the
> expected zone for where it was requested.
>
> This is a reland of commit a247b158d6
>
> Change-Id: Ieec74d6f93c57175c357ec18889144635f5bdca6
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249490
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Reviewed-by: Erik Ernst <eernst@google.com>
TBR=lrn@google.com,eernst@google.com,nbosch@google.com
Change-Id: I870285b03ec05803c5aaa6b66f9a6e6ea360d732
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249609
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
We introduced a `nullFuture` during the null-safety migration where
we changed some methods to no longer allow returning `null`,
and they therefore had to return a `Future`.
That affected timing, because returning `null` was processed
synchronously, and that change in timing made some tests fail.
Rather that fix the fragile tests, we made the function return
a recognizable future, a canonical `Future<Null>.value(null)`,
and then recognized it and took a synchronous path for it.
That caused other issues, because the future was created in the
root zone. (Well, originally, it was created in the first zone
which needed one, that was worse. Now it's created in the root zone.)
Some code tries to contain asynchrony inside a custom zone, and
then the get a `nullFuture` and calls `then` on it, and that
schedules a microtask in the root zone.
(It should probably have used the listener's zone, and not store
a zone in the future at all, but that's how it was first done,
and now people rely on that behavior too.)
This change creates a `null` future *per zone* (lazily initialized
when asked for). That should be sufficient because the code recognizing
a returned `null` future is generally running in the same zone,
but if any other code gets the `nullFuture`, it will be in the
expected zone for where it was requested.
This is a reland of commit a247b158d6
Change-Id: Ieec74d6f93c57175c357ec18889144635f5bdca6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249490
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This reverts commit 4d750a862d.
Reason for revert: breaks google3 (b/236665701)
Original change's description:
> Make `nullFuture` be per-zone.
>
> We introduced a `nullFuture` during the null-safety migration where
> we changed some methods to no longer allow returning `null`,
> and they therefore had to return a `Future`.
> That affected timing, because returning `null` was processed
> synchronously, and that change in timing made some tests fail.
> Rather that fix the fragile tests, we made the function return
> a recognizable future, a canonical `Future<Null>.value(null)`,
> and then recognized it and took a synchronous path for it.
>
> That caused other issues, because the future was created in the
> root zone. (Well, originally, it was created in the first zone
> which needed one, that was worse. Now it's created in the root zone.)
> Some code tries to contain asynchrony inside a custom zone, and
> then the get a `nullFuture` and calls `then` on it, and that
> schedules a microtask in the root zone.
> (It should probably have used the listener's zone, and not store
> a zone in the future at all, but that's how it was first done,
> and now people rely on that behavior too.)
>
> This change creates a `null` future *per zone* (lazily initialized
> when asked for). That should be sufficient because the code recognizing
> a returned `null` future is generally running in the same zone,
> but if any other code gets the `nullFuture`, it will be in the
> expected zone for where it was requested.
>
> This is a reland of commit a247b158d6
>
> Change-Id: Ia113756de1f6d50af4b1abfec219d6b4dcd5d59b
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249488
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: I02d62d58bae33d6a606a80eb3eee2e8e721a8e20
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249620
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
We introduced a `nullFuture` during the null-safety migration where
we changed some methods to no longer allow returning `null`,
and they therefore had to return a `Future`.
That affected timing, because returning `null` was processed
synchronously, and that change in timing made some tests fail.
Rather that fix the fragile tests, we made the function return
a recognizable future, a canonical `Future<Null>.value(null)`,
and then recognized it and took a synchronous path for it.
That caused other issues, because the future was created in the
root zone. (Well, originally, it was created in the first zone
which needed one, that was worse. Now it's created in the root zone.)
Some code tries to contain asynchrony inside a custom zone, and
then the get a `nullFuture` and calls `then` on it, and that
schedules a microtask in the root zone.
(It should probably have used the listener's zone, and not store
a zone in the future at all, but that's how it was first done,
and now people rely on that behavior too.)
This change creates a `null` future *per zone* (lazily initialized
when asked for). That should be sufficient because the code recognizing
a returned `null` future is generally running in the same zone,
but if any other code gets the `nullFuture`, it will be in the
expected zone for where it was requested.
This is a reland of commit a247b158d6
Change-Id: Ia113756de1f6d50af4b1abfec219d6b4dcd5d59b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249488
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reverts commit a247b158d6.
Reason for revert: breaks google3. See b/236665701.
Original change's description:
> Make `nullFuture` be per-zone.
>
> We introduced a `nullFuture` during the null-safety migration where
> we changed some methods to no longer allow returning `null`,
> and they therefore had to return a `Future`.
> That affected timing, because returning `null` was processed
> synchronously, and that change in timing made some tests fail.
> Rather that fix the fragile tests, we made the function return
> a recognizable future, a canonical `Future<Null>.value(null)`,
> and then recognized it and took a synchronous path for it.
>
> That caused other issues, because the future was created in the
> root zone. (Well, originally, it was created in the first zone
> which needed one, that was worse. Now it's created in the root zone.)
> Some code tries to contain asynchrony inside a custom zone, and
> then the get a `nullFuture` and calls `then` on it, and that
> schedules a microtask in the root zone.
> (It should probably have used the listener's zone, and not store
> a zone in the future at all, but that's how it was first done,
> and now people rely on that behavior too.)
>
> This change creates a `null` future *per zone* (lazily initialized
> when asked for). That should be sufficient because the code recognizing
> a returned `null` future is generally running in the same zone,
> but if any other code gets the `nullFuture`, it will be in the
> expected zone for where it was requested.
>
> Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
> Reviewed-by: Nate Bosch <nbosch@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,nbosch@google.com
Change-Id: Ic765eb1401dbff4dea6c08c007c0bf9aff186684
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249188
Reviewed-by: Oleh Prypin <oprypin@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Emmanuel Pellereau <emmanuelp@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Emmanuel Pellereau <emmanuelp@google.com>
We introduced a `nullFuture` during the null-safety migration where
we changed some methods to no longer allow returning `null`,
and they therefore had to return a `Future`.
That affected timing, because returning `null` was processed
synchronously, and that change in timing made some tests fail.
Rather that fix the fragile tests, we made the function return
a recognizable future, a canonical `Future<Null>.value(null)`,
and then recognized it and took a synchronous path for it.
That caused other issues, because the future was created in the
root zone. (Well, originally, it was created in the first zone
which needed one, that was worse. Now it's created in the root zone.)
Some code tries to contain asynchrony inside a custom zone, and
then the get a `nullFuture` and calls `then` on it, and that
schedules a microtask in the root zone.
(It should probably have used the listener's zone, and not store
a zone in the future at all, but that's how it was first done,
and now people rely on that behavior too.)
This change creates a `null` future *per zone* (lazily initialized
when asked for). That should be sufficient because the code recognizing
a returned `null` future is generally running in the same zone,
but if any other code gets the `nullFuture`, it will be in the
expected zone for where it was requested.
Change-Id: Ibe204eaabe175cbcbcb7822ca1f2bcdda72a478c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248660
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Correctness changes:
Fix SEGV by checking for overflow in computing the length of the
repeated string.
Performance changes:
Use unnested loops to fill the string instead of nested loops.
Implement `operator *` for _TwoByteString in the same way.
(The default implementation using StringBuffer causes a lot of
allocations. For example, `"α" * 10000` repeatedly adds the small
string to the StringBuffer, which repeatedly compresses a sequence of
small strings to make a bigger string to stop the list of parts
becoming too large. This compression creates a lot of small strings
with the same contents.)
Bug: 49289
Change-Id: I06c3d91b531d7e4fffc8de9f3bada3eb62ad185f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249122
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
The ! operator causes _CastErrors to be thrown without the
_CastError.{_url,_line,_column} fields to be set (see
runtime/vm/runtime_entry.cc:NullErrorHelper).
This CL makes the fields nullable. An alternative would be to remove the
fields entirely since the fields are not used and the position of the
failed null check is visible from top frame in the stack frame as well.
Though the fields are visible in the debugger and there are other
situations where they are correctly set (e.g. in type errors that cause
_CastError to be thrown). To avoid changing this behavior, we make them
nullable.
Fixes https://github.com/dart-lang/sdk/issues/49279
TEST=vm/dart{,_2}/regress_49279_test
Change-Id: Ieff9e84819d5afa83c8950ad1f99d684d184340a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248980
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Relanding after https://dart-review.googlesource.com/c/sdk/+/244200.
Original change's description:
> [vm] Only call `.hashCode` once when adding to `Map` and `Set`
>
> The methods to add to hash maps and hash sets are recursive: if the
> index needs to be rehashed then the same method is called again
> after rehashing.
>
> This CL nests the actual implementation in a private method that takes
> the full hashCode as an extra argument.
>
> No significant code size or run time changes are reported on our
> benchmarks. (Our benchmarks do not contain purposefully slow hashCodes.)
>
> Note that hashCode can be called again later if rehashing of the index
> is required on adding subsequent elements.
>
> Bug: https://github.com/dart-lang/sdk/issues/48948
> Change-Id: Ia3ccff9e592d675b4922ac78c4aa7ee0287ecb50
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243623
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Daco Harkes <dacoharkes@google.com>
Change-Id: I033bd7cc29fc812dccb6dccf0c3dca6e22cae2ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248802
Commit-Queue: Tess Strickland <sstrickl@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Tess Strickland <sstrickl@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>
The current implementation uses a specialized version of the
pending-event queue used by stream subscriptions to remember
pending events.
That makes the queue polymorphic, and slightly more complicated than
necessary, and that again makes further refactorings of the
Stream implementation harder.
This change moves the logic from the specialized pending-queue
into a simple function instead, so you only pay for it if you
actually use `Stream.fromIterable`.
Also allows `Stream.fromIterable` to be listened to more than once.
(It uses `Stream.multi` for the general async+sync controller API,
and it would cost extra code to make it only work once.)
Change-Id: I44b2010225cd3d32c2bcdb8a315c94881331bdae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248146
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@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>
Fixes#49241
TEST=ci
Change-Id: I6117bf816fc8c4613cce66927f952fef75632725
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248120
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL fixes a number of minor JS interop issues.
* `dartify` was moved to Dart, so we can control implicit coercion from JS
* All JS types are 'correctly' handled in `dartify` though a few are boxed
as opaque types that could be exposed.
* The logic to convert a JS array is now driven from the Dart side.
* Function, Number, and Boolean can now make the roundtrip through Dart.
* The wrapper for Dart functions in JS is now a regular JS function.
Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try
Change-Id: Ifcd7a447419bca2adf78070e07750c1b3c5c6a18
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247925
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
From Dart language specification (17.15 Function Invocation):
If execution of the body returns an object, o is completed with that
object. If it completes normally or returns without an object,
o is completed with the null object (17.4), and if it throws
an exception e and stack trace t, o is completed with the error e and
stack trace t. If execution of the body throws before the body suspends
the first time, completion of o happens at some future time after the
invocation has returned. The caller needs time to set up error handling
for the returned future, so the future is not completed with
an error before it has been returned.
So far, implementation of async functions in Dart VM postponed
completion of the Future both with the value and with an error
if execution has not reached the first await. This change modifies
the behavior to compile future with value immediately even if
the first await was not reached. Completion with an error is still
postponed.
This change in behavior will let us improve performance of
async/await in certain cases.
The new behavior still conforms to the Dart language specification.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: I0e80a1d0dd0c3cd6acbc640681e7b06bbf81c19c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243101
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This reverts commit 5875a9ba9d.
Reason for revert: We seem to have some cbuild failures, logs can be found here 5875a9ba9d
Original change's description:
> Avoid computing the URI scanner tables at runtime.
>
> Precompute the table and store it as a String literal.
>
> Fixes#49108.
>
> Bug: https://dartbug.com/49108
> Change-Id: I33d3e768ad2013ad2edec3558fcd3da39b3f4f32
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247383
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Auto-Submit: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,vegorov@google.com,kustermann@google.com
Change-Id: I3c2609aad7944ea9118af14733c3e99db9902297
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://dartbug.com/49108
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247860
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This reverts commit 69f32d6ad7.
Reason for revert: We seem to have a number of tests failing with timeouts in CBUILD after this change, please see logs at
69f32d6ad7
Original change's description:
> Refactor `_Future`.
>
> This is a major rewrite of the `_Future` class,
> which is the default implementation of the `Future` interface.
>
> The main goal was to reduce the number of expensive type checks
> in the internal passing around of data.
> Expensive type checks are things like
> * `is _Future<T>` (more expensive than just `is _Future`, the latter
> can be a single class-ID check.
> * Covariant generic parameter checks (using `T` covariantly in a
> parameter forces a run-time type check).
>
> Also removed some plain unnecessary casts and turned some
> implicit casts from `dynamic` into `unsafeCast`s.
>
> This seems to be an success, at least on very primitive benchmarks, according to Golem:
> FutureCatchErrorTest 41.22% (1.9 noise)
> FutureValueTest 46.51% (2.8 noise)
> EmptyFutureTest 59.15% (3.1 noise)
> FutureWhenCompleteTest 51.10% (3.2 noise)
>
> A secondary goal was to clean up a very old and messy class,
> and make it clearer for other `dart:async` how to interact
> with the future.
>
> The change has a memory cost: The `_FutureListener<S,T>` class,
> which represents a `then`, `catchError` or `whenComplete`
> call on a `_Future`, now contains a reference to its source future,
> the one which provides the inputs to the callbacks,
> as well as the result future returned by the call.
> That's one extra memory slot per listener.
>
> In return, the `_FutureListener` now does not need to
> get its source future as an argument, which needs a covariant
> generic type check, and the methods of `_Future` can be written
> in a way which ignores the type parameters of both `_Future`
> and `_FutureListener`, which reduces complex type checks
> significantly.
>
> In general, typed code is in `_FutureListener`, which knows both
> the source and target types of the listener callbacks, and which
> contains the futures already at that type, so no extra type checking
> is needed.
> The `_Future` class is mostly untyped, except for its "public"
> API, called by other classes, which checks inputs,
> and code interacting with non-native futures.
> Invariants ensure that only correctly typed values
> are stored in the untyped shared `_resultOrListeners` field
> on `_Future`, as determined by its `_state` integer.
> (This was already partially true, and has simply been made
> more consistent.)
>
> Further, we now throw an error in a situation that was previously
> unhandled: When a `_Future` is completed with *itself*.
> That would ensure that the future would never complete
> (it waits for itself to complete before it can complete),
> and may potentially have caused weird loops in the representation.
> In practice, it probably never happens. Now it makes the error
> fail with an error.
> Currently a private `_FutureCyclicDependencyError` which presents
> as an `UnsupportedError`.
> That avoids code like
> ```dart
> import "dart:async";
> void main() {
> var c = Completer();
> c.complete(c.future); // bad.
> print("well!");
> var d = Completer();
> d.complete(c.future);
> print("shucks!");
> }
> ```
> from hanging the runtime by busily searching for the end of a cycle.
>
> See https://github.com/dart-lang/sdk/issues/48225
> Fixes#48225
>
> TEST= refactoring covered by existing tests, few new tests.
>
> Change-Id: Id9fc5af5fe011deb0af3e1e8a4ea3a91799f9da4
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244241
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Lasse Nielsen <lrn@google.com>
TBR=lrn@google.com,kustermann@google.com,sra@google.com,sigmund@google.com,nshahan@google.com
Change-Id: I455be5a04b4c346df26d4ded0fa7388baccb0f8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247762
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This is a major rewrite of the `_Future` class,
which is the default implementation of the `Future` interface.
The main goal was to reduce the number of expensive type checks
in the internal passing around of data.
Expensive type checks are things like
* `is _Future<T>` (more expensive than just `is _Future`, the latter
can be a single class-ID check.
* Covariant generic parameter checks (using `T` covariantly in a
parameter forces a run-time type check).
Also removed some plain unnecessary casts and turned some
implicit casts from `dynamic` into `unsafeCast`s.
This seems to be an success, at least on very primitive benchmarks, according to Golem:
FutureCatchErrorTest 41.22% (1.9 noise)
FutureValueTest 46.51% (2.8 noise)
EmptyFutureTest 59.15% (3.1 noise)
FutureWhenCompleteTest 51.10% (3.2 noise)
A secondary goal was to clean up a very old and messy class,
and make it clearer for other `dart:async` how to interact
with the future.
The change has a memory cost: The `_FutureListener<S,T>` class,
which represents a `then`, `catchError` or `whenComplete`
call on a `_Future`, now contains a reference to its source future,
the one which provides the inputs to the callbacks,
as well as the result future returned by the call.
That's one extra memory slot per listener.
In return, the `_FutureListener` now does not need to
get its source future as an argument, which needs a covariant
generic type check, and the methods of `_Future` can be written
in a way which ignores the type parameters of both `_Future`
and `_FutureListener`, which reduces complex type checks
significantly.
In general, typed code is in `_FutureListener`, which knows both
the source and target types of the listener callbacks, and which
contains the futures already at that type, so no extra type checking
is needed.
The `_Future` class is mostly untyped, except for its "public"
API, called by other classes, which checks inputs,
and code interacting with non-native futures.
Invariants ensure that only correctly typed values
are stored in the untyped shared `_resultOrListeners` field
on `_Future`, as determined by its `_state` integer.
(This was already partially true, and has simply been made
more consistent.)
Further, we now throw an error in a situation that was previously
unhandled: When a `_Future` is completed with *itself*.
That would ensure that the future would never complete
(it waits for itself to complete before it can complete),
and may potentially have caused weird loops in the representation.
In practice, it probably never happens. Now it makes the error
fail with an error.
Currently a private `_FutureCyclicDependencyError` which presents
as an `UnsupportedError`.
That avoids code like
```dart
import "dart:async";
void main() {
var c = Completer();
c.complete(c.future); // bad.
print("well!");
var d = Completer();
d.complete(c.future);
print("shucks!");
}
```
from hanging the runtime by busily searching for the end of a cycle.
See https://github.com/dart-lang/sdk/issues/48225Fixes#48225
TEST= refactoring covered by existing tests, few new tests.
Change-Id: Id9fc5af5fe011deb0af3e1e8a4ea3a91799f9da4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244241
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Precompute the table and store it as a String literal.
Fixes#49108.
Bug: https://dartbug.com/49108
Change-Id: I33d3e768ad2013ad2edec3558fcd3da39b3f4f32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247383
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Auto-Submit: Lasse Nielsen <lrn@google.com>
This ensures the TFA doesn't tree shake Function members.
Change-Id: I23374d1bb9aec118906e2b8211d987046a3bbafb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247502
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This reverts commit abfdc3d50f.
Reason for revert: breaks on internal roll - b/235267735 and others can be fixed in advance of landing this
Original change's description:
> Remove SCREAMING dart:io networking APIs
>
> Bug: https://github.com/dart-lang/sdk/issues/49140
> Change-Id: I50c6cca26597ee4d469b776fcec412ddfed760e1
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246962
> Reviewed-by: Paul Berry <paulberry@google.com>
> Commit-Queue: Michael Thomsen <mit@google.com>
TBR=mit@google.com,paulberry@google.com
Change-Id: I55a43cc1bd7435fe7824f7ca8098575232fdcf2f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/49140
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247389
Commit-Queue: Oleh Prypin <oprypin@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Oleh Prypin <oprypin@google.com>
This CL consists of:
1) Moving most of the contents of `js_util_wasm_patch` to
`js_util_patch` and `js_helper`.
2) Addressing the inconsistencies between `js_util` and `js_util_wasm`.
3) Fixing a minor bug with nested `allowInterop` in
`js_util_wasm_optimizer`.
4) Removing hardcoded eval.
Change-Id: Ie43cdc91d344745ef9b40e273192b34af2a84138
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246380
Commit-Queue: Joshua Litt <joshualitt@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Closes#49165
The empty string argument can be confusing to read since it is not clear
what it means. Allow omitting the argument entirely to default to an
empty path.
R=lrn@google.com
Change-Id: I05ca432a679a0df751a16d1beb241b14f80d4681
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246988
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
The new implementation is based on suspend/resume stubs and doesn't
use desugaring of async functions on kernel AST.
Previously, new implementation of async/async* was only supported in
AOT mode. This change adds all necessary bits for the JIT mode:
* Suspending variable-length frames (for unoptimized code).
* Handling of Code and pool pointers in Dart stack frames.
* OSR.
* Deoptimization.
* Hot reload.
* Debugger.
The new implementation is not enabled in JIT mode yet.
Design doc: go/compact-async-await.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: I477d6684bdce7cbc1edb179ae2271ff598b7dcc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246081
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This reverts commit 6de162e014.
Reason for revert: Local testing of a large Flutter app with this change causes the app to crash on startup
Original change's description:
> [vm, compiler] Prune dictionaries to only contain elements needed at runtime.
>
> flutter_gallery
> Isolate(CodeSize): 2116400 -> 1981238 (-6.28%)
> Total(CodeSize): 7217938 -> 7082600 (-1.87%)
>
> TEST=ci
> Bug: https://github.com/dart-lang/sdk/issues/48910
> Change-Id: I8cd285ddab3a611cd7a2a91d50414be402f8543a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244303
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: https://github.com/dart-lang/sdk/issues/48910
Change-Id: Ie51f004e84970907fa1233e8e7c3ed63e2da1c4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246683
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This is breaking change #45630.
The Dart VM has until now restored the terminal settings upon exit to
their initial values for stdin, stdout, and stderr. This change removes
that automatic behavior in favor of having the program do the
restoration. Previously the intention was that dart programs can
enable/disable echoing and line buffering and not worry about restoring
the original settings.
However, the VM doing so unconditionally leads to undesirable behavior
e.g. when the program does not care about terminal settings and is
sharing a process group with a program that does care. E.g. if dart's
output is piped into less(1), then there is a race condition where dart
might see the raw terminal settings set by less(1), and if the dart VM
exits after less(1) has exited, then it will restore the raw terminal
settings, leaving the user with a seemingly defective shell with echo
disabled. This race condition can be reproduced using:
cat > yes.dart << EOF
main() {
for (int i = 0; i < 1000000; i++) {
print("yes");
}
}
EOF
stty; (sleep 1 && dart yes.dart) | less; stty; stty sane
The user will end up with a shell with echo behavior disabled. The stty
command shows the current terminal settings, where the difference can be
seen, and 'stty sane' fixes the settings before returning to the shell
prompt. The 'stty sane' call can be omitted to see the defective shell
prompt.
This change removes the terminal restoring behavior (added in Dart
2.0.0) and instead asks applications to do the restoration themselves.
The new design matches how programs in other programming languages
implement interactive input that changes terminal settings.
Furthermore the `echoMode` setting now only controls the `echo` local
mode and no longer sets the `echonl` local mode on POSIX systems (which
controls whether newline are echoed even if the regular echo mode is
disabled). The `echonl` local mode is usually turned off in common shell
environments. Programs that wish to control the `echonl` local mode can
use the new `echoNewlineMode` setting. This change is required to
prevent the reoccurence of #30318 when programs manually restore
`echoMode`.
Windows has further considerations: It also saves the console code pages
and restore them if they were not UTF-8. This behavior is retained as it
is useful and needed for Dart's output to function properly. ANSI output
sequences are also turned on via ENABLE_VIRTUAL_TERMINAL_PROCESSING,
which is slightly changed in this change to only rsetore that setting if
it wasn't already on for consistency.
Closes https://github.com/dart-lang/sdk/issues/36453
Closes https://github.com/dart-lang/sdk/issues/45630
TEST=Reproduced with less as above
Change-Id: I2991f9c7f47b97fe475c1ad6edeb769024f8d0db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190484
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
- Files in the SDK are already opted into null safety.
- Files in the packages are already opted into null safety via
the pubspecs.
- in_sync_test.dart was opted out but required no changes to
migrate.
Change-Id: Ic9334824de1b22c879e962f488e1fa8021017710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246058
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
When compiling the Dart SDK with the `--canary` flag DDC will include
the new shared runtime type library in the compiled SDK.
Change-Id: I7a418033fb7397939aa6f4b7fb84820ead99c3be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241690
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Creates a new 'dart:_js_shared_embedded_names' library for the names
accessed from the shared 'dart:_rti' library. Migrate all of the shared
symbols and uses to the new location.
Change-Id: Iaa72c4522888ad630782b921b0b70d7a2626d1b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241507
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
The `_CompactIterableImmutable` does not check for concurrent
modifications, because the underlying map is immutable.
The comment was wrong.
Change-Id: I992d841cb6b42d027e8ae5bb853c8345a0f7a69d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/245160
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
These libraries will be shared between the dart2js and DDC runtimes.
Also renames the `shared` directory to `synced` to avoid confusion.
Synced directories are copied to be in sync with the compilers and
runtimes.
Change-Id: Ic36076938741d7102792f09413666de0033da3a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238300
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
The file type of file backing unix domain sockets was being incorrectly
set as kDoesNotExist resulting in errors when operations like delete
on the file was done. File::Exists on the other hand returned true.
File rename and copyfile functionality have been fixed too.
TEST=new tests added
Please see https://github.com/dart-lang/sdk/issues/48569 for the original issue.
Change-Id: I28505236fbad2ea86ad65065e753b13fb7ff655a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240300
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This allows the package to be discoverable across web backends
Change-Id: I7d870a7232543d3b719d47de1424017d7f578434
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244261
Commit-Queue: Mark Zhou <markzipan@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
These classes were introduced only because `_ZoneFunction`
could not take a generic type argument at the time.
It can now.
Change-Id: Id8dd75946176ef19350b33df905288a851982d3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244400
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Auto-Submit: Lasse Nielsen <lrn@google.com>
This adds a --platform= option to dart2wasm to read the SDK libraries
from that dill file instead of compiling them from source every time.
If the option is not given, the SDK libraries are compiled, like before.
Also adds a "dart2wasm" build target, which will build the dart2wasm
platform dill and compile dart2wasm to two AOT snapshots (with and
without asserts). The dart2wasm scripts in sdk/bin are updated to run
via these snapshots and use this platform dill.
This speeds up test runs for the dart2wasm-hostasserts-linux-x64-d8
configuration by approximately 45x.
Change-Id: If2c7750a6eb39725310745f887792784d0dfc583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243624
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
