The legacy Dart 2.9 benchmarks that used the default List(int size)
constructor are changed to use the equivalent List.filled(size, null)
constructor, because the default List constructor is removed.
Bug: b/280275041
Change-Id: I2813537ae22e19d473abde70d677368940585423
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304700
Reviewed-by: Jonas Termansen <sortie@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Change-Id: I63b829e107458268d91b39e7f0abb673dc20d0f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304004
Commit-Queue: William Hesse <whesse@google.com>
Auto-Submit: Erik Ernst <eernst@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Add the `IOSSdk` so it can be passed in from flutter_tools.
Change-Id: If0d4e6c90b4cf94b555b3f3097f66e4d64a50130
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303741
Commit-Queue: Hossein Yousefi <yousefi@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Hossein Yousefi <yousefi@google.com>
Threads that own safepoint operations (e.g. a thread owning
[ReloadSafepointOperation]) are free to exit & re-enter. Owning a
safepoint operation only means that other threads are at well defined
places.
We limit the number of active mutators that can be running at the same
time - mainly due to the way our GC works today. This is maintained by
threads blocking on entering when there's too many mutators already.
If a thread owns a safepoint operation and exits, it should not give up
it's mutator slot to ensure it will be able to re-enter.
A concrete case when this can happen: We have many isolates and we run
in `--hot-reload-test-mode`. One isolate will own a reload safepoint
operation & perform reload. As part of reload it will exit the isolate
and send a request to the `kernel-service` and wait for it's reply. Once
it gets a replay it will re-enter the isolate. Now this re-entering
could be blocking if another thread took the mutator slot (which can
happen, as we get mutator slot before we try to check-in to safepoint
when entering).
In the future we may unify the safepoint mechanism with the mutator
count mechanism.
Closes https://github.com/dart-lang/sdk/issues/52441
TEST=Fixes flaky timeouts of ffi/invoke_callback_after_suspension_test
Change-Id: Icc5dbf59b4270653c9e6e316531f5b3e086db2fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304682
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL re-implements the async function compilation without using JSPI
or any other platform features.
This implementation is faster than the JSPI-based one in all benchmarks,
in some cases up to 200x (benchmark results at the end). So we remove
the JSPI-based implementation as there's no point in maintaining a much
slower implementation and supporting two implementations at the same
time (which is tricky because these implementations need different
libraries, all scripts need to support two modes etc.) that also
requires experimental platform features.
# Main changes
- A new pass `AwaitTransformer` transforms `await` expressions to
top-level statements in form `var <fresh variable> = await <simple
expr>`, where `<simple expr>` is an expression without `await`.
After this pass all `await` expressions have the simple continuation
of "assign the value of the awaited future to this variable and
continue with the next statement". This simplifies `await`
compilation.
- A new code generator `AsyncCodeGenerator` (inherits from
`CodeGenerator`) compiles `async` functions. The `_YieldFinder` class
is copied from `sync*` code generator but modified to handle `async`
expressions.
- Mentions to the V8 flag `--experimental-wasm-stack-switching` is
removed from all scripts and documents.
# Future work
- Control flow handling in `AsyncCodeGenerator` needs to be implemented
in a similar way in `SyncStarCodeGenerator`. Doing this without
duplicating a lot of code will require some refactoring.
# New passing tests
- co19/Language/Statements/Yield_and_Yield_Each/Yield/execution_async_A05_t01
- co19/Language/Statements/For/Asynchronous_For_in/execution_A02_t02
- language/regress/regress23996_test
- language/sync_star/dcall_type_test
# Benchmarks
Current implementation:
```
AsyncLiveVars.LiveObj1(RunTime): 1586000.0 us.
AsyncLiveVars.LiveObj2(RunTime): 2114000.0 us.
AsyncLiveVars.LiveObj4(RunTime): 1972500.0 us.
AsyncLiveVars.LiveObj8(RunTime): 2212000.0 us.
AsyncLiveVars.LiveObj16(RunTime): 2238000.0 us.
AsyncLiveVars.LiveInt1(RunTime): 2362000.0 us.
AsyncLiveVars.LiveInt4(RunTime): 2470000.0 us.
AsyncLiveVars.LiveObj2Int2(RunTime): 2575000.0 us.
AsyncLiveVars.LiveObj4Int4(RunTime): 2820000.0 us.
Calls.AwaitAsyncCall(RunTimeRaw): 35676.15658362989 ns.
Calls.AwaitAsyncCallClosureTargetPolymorphic(RunTimeRaw): 38934.108527131786 ns.
Calls.AwaitAsyncCallInstanceTargetPolymorphic(RunTimeRaw): 42617.02127659575 ns.
Calls.AwaitFutureCall(RunTimeRaw): 2832.058906825262 ns.
Calls.AwaitFutureCallClosureTargetPolymorphic(RunTimeRaw): 3665.8125915080527 ns.
Calls.AwaitFutureCallInstanceTargetPolymorphic(RunTimeRaw): 4420.449537241076 ns.
Calls.AwaitFutureOrCall(RunTimeRaw): 3692.7621861152143 ns.
Calls.AwaitFutureOrCallClosureTargetPolymorphic(RunTimeRaw): 4625.346901017576 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphic(RunTimeRaw): 4514.6726862302485 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphicManyAwaits(RunTimeRaw): 345172.4137931034 ns.
Calls.AwaitForAsyncStarStreamPolymorphic(RunTimeRaw): 697000.0 ns.
Calls.AwaitForAsyncStarStreamPolymorphicManyYields(RunTimeRaw): 704666.6666666666 ns.
Calls.AwaitForManualStreamPolymorphic(RunTimeRaw): 11010.989010989011 ns.
Calls.SyncCall(RunTimeRaw): 0.40275240996973316 ns.
Calls.SyncCallClosureTarget(RunTimeRaw): 0.3989591156672242 ns.
Calls.SyncCallInstanceTargetPolymorphic(RunTimeRaw): 3.2632549336335526 ns.
Calls.IterableSyncStarIterablePolymorphic(RunTimeRaw): 353.3980582524272 ns.
Calls.IterableManualIterablePolymorphic(RunTimeRaw): 332.1161825726141 ns.
Calls.IterableManualIterablePolymorphicManyYields(RunTimeRaw): 354.28067078552516 ns.
```
New implementation:
```
AsyncLiveVars.LiveObj1(RunTime): 11327.683615819209 us.
AsyncLiveVars.LiveObj2(RunTime): 10923.91304347826 us.
AsyncLiveVars.LiveObj4(RunTime): 10956.284153005465 us.
AsyncLiveVars.LiveObj8(RunTime): 11286.516853932584 us.
AsyncLiveVars.LiveObj16(RunTime): 11445.714285714286 us.
AsyncLiveVars.LiveInt1(RunTime): 11016.483516483517 us.
AsyncLiveVars.LiveInt4(RunTime): 11327.683615819209 us.
AsyncLiveVars.LiveObj2Int2(RunTime): 10918.478260869566 us.
AsyncLiveVars.LiveObj4Int4(RunTime): 10737.967914438503 us.
Calls.AwaitAsyncCall(RunTimeRaw): 1082.2510822510822 ns.
Calls.AwaitAsyncCallClosureTargetPolymorphic(RunTimeRaw): 1056.4124234100993 ns.
Calls.AwaitAsyncCallInstanceTargetPolymorphic(RunTimeRaw): 1134.1726210729273 ns.
Calls.AwaitFutureCall(RunTimeRaw): 865.6509695290858 ns.
Calls.AwaitFutureCallClosureTargetPolymorphic(RunTimeRaw): 841.3967185527977 ns.
Calls.AwaitFutureCallInstanceTargetPolymorphic(RunTimeRaw): 839.066957543212 ns.
Calls.AwaitFutureOrCall(RunTimeRaw): 397.9941096871766 ns.
Calls.AwaitFutureOrCallClosureTargetPolymorphic(RunTimeRaw): 406.17384240454913 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphic(RunTimeRaw): 393.7472929873607 ns.
Calls.AwaitFutureOrCallInstanceTargetPolymorphicManyAwaits(RunTimeRaw): 1095.0503723171266 ns.
Calls.AwaitForAsyncStarStreamPolymorphic(RunTimeRaw): 6643.426294820717 ns.
Calls.AwaitForAsyncStarStreamPolymorphicManyYields(RunTimeRaw): 7178.750897343863 ns.
Calls.AwaitForManualStreamPolymorphic(RunTimeRaw): 1456.23998835008 ns.
Calls.SyncCall(RunTimeRaw): 0.3919935321067202 ns.
Calls.SyncCallClosureTarget(RunTimeRaw): 0.3906669661780074 ns.
Calls.SyncCallInstanceTargetPolymorphic(RunTimeRaw): 3.1676143112814583 ns.
Calls.IterableSyncStarIterablePolymorphic(RunTimeRaw): 104.4932079414838 ns.
Calls.IterableManualIterablePolymorphic(RunTimeRaw): 104.57516339869281 ns.
Calls.IterableManualIterablePolymorphicManyYields(RunTimeRaw): 116.92487576731949 ns.
```
TEST=ci
CoreLibraryReviewExempt: Added entry-point pragmas.
Change-Id: I02fbd08141f51c00fb37b6fa0304dc25d6afdb71
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301020
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This test verifies stack traces of certain type errors.
In AOT mode, stack traces only contain line numbers but not columns.
So, the test is updated to accomodate for AOT stack traces.
Also, the test is skipped in 'dwarf' and 'obfuscated' modes as
they don't provide symbolic stack traces.
Change-Id: I5a590b13c9ecaffbd4a495441fc66f807d942a12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304208
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
When promoting fields, in order to avoid unsoundness, we need to
distinguish between field accesses performed through `super` and field
accesses performed through `this`. Otherwise, a user could do
something like this:
class B {
final int? _i;
B(this.i);
}
class C extends B {
final int? _i;
C(this._i, int? superI) : super(superI);
int f() {
if (super._i != null) {
return this._i; // UNSOUND: `this._i` could be `null`
}
}
}
To avoid this problem, flow analysis now uses separate promotion keys
for `super` and `this`, so that promoting a variable through `this`
leaves it unpromoted when accessed via `super`, and vice versa.
Note that in principle the implementations could inspect the enclosing
class, and only distinguish `this.` and `super.` accesses in the case
where it contains a declaration matching the field name. But doing so
would carry a performance and implementation complexity cost, and
would confer very little real-world benefit (since in practice users
don't mix `this.` and `super.` accesses and expect them to refer to
the same field).
Fixes#50138.
Bug: https://github.com/dart-lang/sdk/issues/50138
Change-Id: Ia0fd79b5ed7649d23a28efcbffb59b4c9ad63f70
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304364
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests are based on the unit tests I wrote during development of
the flow analysis support for patterns; as such, they are not
especially uniform in their coverage, but they should be a good
start. I intend to expand coverage in future CLs.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: I23bd96621a0269c1e642a7fa3b65c851357505c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304320
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Avoid reporting an error if the static types are mismatched because
CompileTimeErrorCode.INVALID_ASSIGNMENT would have already been
reported by the ErrorVerifier.
Closes#37238
Bug: https://github.com/dart-lang/sdk/issues/37238
Change-Id: I2248d054ed6bf6a546e998afb9b731a36e197780
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304362
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
This is work towards https://github.com/dart-lang/sdk/issues/47968. The fix processor may need to be called multiple times to fix all issues because some fixes may produce code that can be fixed by another (for example one inserting "final" and then another replacing it with "const").
In order to be able to provide multiple passes of edits to LSP, we need to merge them together because LSP's edits are not applied sequentially but must all represent valid locations in the original source file.
This class is currently unused (besides tests).
Change-Id: Ia006ff8044505c6d109f6480f7bcce4da4669cdb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304180
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
I played with it some more, and found that the overhead of measuring
too fine grainly, when we have tens and hundreds thousands of relatively
inexpensive operations, is too high.
Change-Id: I4038e3972efff860d568c02008120092f99b8298
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304368
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
I saw that the linter roll reported a strange InvalidType related
error. So, I wanted to check if this is something I can reproduce.
I cannot, but the tests might be useful anyway.
Change-Id: I21138685c4fee028f0620d3fcfa3a221a304c951
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304325
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
These were original getters without any fields. After adding fields
to cache the values instead of rereading them on each access the
forwarding public getters became redundant but were not removed.
Make the fields public, remove the getters, and move the docs from the
getters to the fields.
Change-Id: Ie078f5b85cf85f8f86642ac6fe8d36f4107602ee
CoreLibraryReviewExempt: Only impacts VM platform.
Tested:No behavior changes expected. Confirmed updated fields can be read on VM.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304324
Reviewed-by: Siva Annamalai <asiva@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
This fixes the asan failure, but not the ubsan failure.
Bug: https://github.com/dart-lang/sdk/issues/52440
Change-Id: I29d9b153fd14349477a68bd341b035e8783fd29d
TEST=DuplicateRXVirtualMemory
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304400
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Auto-Submit: Liam Appelbe <liama@google.com>
The changes are:
* Use the current tear-off syntax for constuctors in the example
* Add references to the code where certain maps are defined.
Change-Id: I5710090c1ecb2939d74a3822b8c7b35090be378c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304323
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Adds a delegating reporter so we can keep track of whether there are
interop errors. If there are, we do not do the transforms on the JS
backends.
Change-Id: Ib0f36b748443cb7fe8f8bb427692d653557d59fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304261
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a reland of commit 43ce5487c1
In addition to removing type check, switch range checks are adjusted
in order to avoid call to 'int.operator<=', which can be removed by
tree shaker in AOT/product mode, causing NoSuchMethodError at runtime.
Original change's description:
> [vm/compiler] Remove unnecessary type check from optimized switches
>
> Switch optimization now relies on static type of the tested value,
> so it is safe to omit the type check (with sound null safety) or
> reduce it to a null check (without sound null safety).
>
> TEST=co19/LanguageFeatures/Patterns/Exhaustiveness/exhaustiveness_enum_A01_t01
> Fixes https://github.com/dart-lang/sdk/issues/52422
>
> Change-Id: Ic93f4f212bee9ed3bfe5035f3c8d7535274c2f63
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304102
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Alexander Aprelev <aam@google.com>
TEST=co19/LanguageFeatures/Patterns/Exhaustiveness/exhaustiveness_enum_A01_t01
TEST=language/async/switch_test
Change-Id: I70bf480bf376f946d66caa504120c8f85093ea8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304322
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The scope of the lock is coarsened from per-element to per-page. This effectively causes the concurrent sweeper to pause during a scavenge in the case the sweeper encounters empty pages, preventing the sweeper from performing munmap during the scavenge.
TEST=ci
Change-Id: I7b2b077c748234e6d3dc48e2229c546d854ca93a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303087
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This reverts commit 43ce5487c1.
Reason for revert: test failures on vm-aot-*-product-* bots.
Original change's description:
> [vm/compiler] Remove unnecessary type check from optimized switches
>
> Switch optimization now relies on static type of the tested value,
> so it is safe to omit the type check (with sound null safety) or
> reduce it to a null check (without sound null safety).
>
> TEST=co19/LanguageFeatures/Patterns/Exhaustiveness/exhaustiveness_enum_A01_t01
> Fixes https://github.com/dart-lang/sdk/issues/52422
>
> Change-Id: Ic93f4f212bee9ed3bfe5035f3c8d7535274c2f63
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304102
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Alexander Aprelev <aam@google.com>
Change-Id: Ifa6ee75be49f7264fa4dfc08183d5ccb731c60d1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304321
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
The actual removal will happen in (to be rebased on top of this):
https://dart-review.googlesource.com/c/sdk/+/303280
Fixing direct uses of the deprecated `Identifier get name` is apparently
only about a half of the work. I should have followed my own advice to
the clients and prepared better.
These changes are necessary because we will stop creating and
visiting `Identifier`, and so `NamedType` should be handled directly.
Change-Id: Ie07b75b15eab277ed6c9b29a838561a7eb71f588
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303425
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This allows users of Visual Studio Code to open the sdk/ directory.
Without this, attempting to open the root of the repository results
in over 200k analyzer errors eventually hanging/crashing VSCode.
This matches what Fuschia and other large projects do to be able
to open large monorepo checkouts in VSCode. e.g.
https://fuchsia.googlesource.com/fuchsia/+/main/fuchsia.code-workspace
Bug: https://github.com/dart-lang/sdk/issues/52380
Change-Id: I1a69627bb6ca25e8f7f036a50534eaf0804e893e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303841
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Devon Carew <devoncarew@google.com>
Auto-Submit: Eric Seidel <eric@shorebird.dev>
The bug is that the disassembler doesn't do any bounds checking, other
than the outer while loop in Disassembler::Disassemble. For multi byte
instructions it relies on having well-formed input to avoid OOB errors.
This test is testing something that doesn't happen in real disassembly,
because usually the invalid machine code is embedded in valid machine
code, so there would be plenty of buffer between the invalid section
and the end of the input. The ideal fix would be to rewrite the
disassembler to do bounds checks, but short of that we can just add
some buffer to the end of bad_input.
Bug: https://github.com/dart-lang/sdk/issues/52421
Change-Id: If68d5485a130523ddf2a4d37f1c8e2ddf1cf485a
Fixes: https://github.com/dart-lang/sdk/issues/52421
TEST=Disassembler_InvalidInput
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304240
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Auto-Submit: Liam Appelbe <liama@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
