TEST=pkg/vm_service/test/get_queued_microtasks_rpc_test
CoreLibraryReviewExempt: This CL does not include any core library API
changes, only VM Service implementation changes within
sdk/lib/vmservice/.
Change-Id: Ie5488f498e4d0f3d201e3f31423fd5029b74a726
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425160
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Remove use of svg, use unicode characters instead.
Run dart format on observatory sources.
Sort import statements with import_sorter.
No functional changes.
TEST=ci, manual
Change-Id: I7e4f67be06a27c8ab510ae8e50ce30b162780d30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426683
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This change makes it so that when the VM detects that a timer is at
least 100 ms overdue, it sends a warning in a VM Service event on the
'Timer' stream.
TEST=Built an Android Flutter app with a modified Engine that contained
a `sleep` call in `eventhandler_linux.cc` and confirmed that the warning
event got sent, built an iOS Flutter app with a modified Engine that
contained a `sleep` call in `eventhandler_macos.cc` and verified that
the warning event got sent,
pkg/vm_service/test/overdue_timer_detection_test
CoreLibraryReviewExempt: This CL does not include any core library API
changes, only VM Service implementation changes.
Change-Id: Ie8db047116b7f63cfb5413f763eaf56c7bdd6975
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/409500
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
There were `pubspec.yaml` files in `tools/` that were not
included in the global package config.
That means that their imports were irrelevant, which could
be misleading. And if any tool would look at the
`pubspec.yaml` file, it might be inconsistent with
the actual package resolution.
Makes every `pubspec.yaml` file either be included by the
`tools/generate_package_config.dart` script, or deletes them
if they seem to be stale and unused.
(Compare vs. `git ls-files '**/pubspec.yaml'`.)
Excepted `tools/dart2js/sourceMapViewer/pubspec.yaml`.
The entire directory might be stale. The dependencies of
that pubspec are not SDK dependencies otherwise,
the pubspec has no SDK min-version, which is now a requirement,
and the README refers to a *packages directory*.
Keeping as-is and filing issue to have owners take a look.
Added `lib/` directory to `tools/` to avoid `tools/bots/`
being inside the package URI root of the `tools/` package,
which would cause its `../../pkg/...` import to fail.
Makes every `pubspec.yaml` file use a `^...` SDK constraint instead
of the longer `>= ... < ...` format.
Tested: No new tests, goal is to keep running the same way
Change-Id: I688e463fe985fc4de43550a1f4c7ff350536cffc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414020
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Given input on stdin it has no path to resolve the relative paths that
exists in a status file from. It will thus complain about almost all
lines which is not ideal.
This CL changes it so it doesn't check for it when given data on stdin.
This also means that - because there are no old errors on that account -
if there are such errors now you will be forced to fix it.
The current errors in the status files I could find have also been
fixed.
This should for instance have flaggen when I in
https://dart-review.googlesource.com/c/sdk/+/400320 updated the
pkg.status file but forgot to actually rename the underlying file
(as fixed in https://dart-review.googlesource.com/c/sdk/+/400560).
Technically I suppose it _did_ flag it, but there were also hundreds of
lines of false positives caused by the old status file been given at
stdin to check if there were existing errors - which there then was, thus not forcing me to do anything.
Logical follow-up to https://dart-review.googlesource.com/c/sdk/+/370886
TEST=ci
Change-Id: Ib3533ede88b6d99a31f8b423c00930857e0ba49f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400620
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
service/get_object_rpc_test was failing because one ID in it hadn't been
updated to the new format.
service/bad_reload_test was failing because `ServiceEvent::PrintJSON`
was attempting to populate the `reloadError` property of every `Event`
of kind `IsolateReload` with an `@Error`, but it was not possible to
allocate IDs for these `@Error`s because `ReloadSources` runs for an
isolate group, not for an individual isolate. I fixed this by removing
the `reloadError` property and adding a `reloadFailureReason` property
with type `string`.
TEST=confirmed that service/bad_reload_test and
service/get_object_rpc_test complete successfully on a local build of
the linux-debug-x64 SDK, vm-linux-debug-x64 tryjob
Issue: https://github.com/dart-lang/sdk/issues/55869
Change-Id: Ibf507aa0e475a6b9bed42b055e9d19b54aa81844
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382661
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This reverts commit 3370a4e393.
Reason for revert: Fixes landed in google3 (cl/650630536).
Original change's description:
> Revert "Reapply "[ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer""
>
> This reverts commit 44d4451476.
>
> Reason for revert: b/350443042
>
> Original change's description:
> > Reapply "[ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer"
> >
> > In the previous version of this change, if the user had 'dart' on their
> > PATH and invoked 'dart compile js' (which spawns the VM service after
> > compilation completes), the VM service would attempt to spawn DDS using
> > './dart' as the executable path instead of 'dart'. This would result in
> > DDS failing to start, causing the VM to print an error and hang.
> >
> > This updated change checks to see if the parent directory of
> > `Platform.executable` is '.' and then verifies if './dart' exists or
> > not. If it doesn't, 'dart' is likely on the user's PATH and should be
> > used directly as the executable path.
> >
> > See https://github.com/dart-lang/sdk/issues/56087 for details.
> >
> > This reverts commit 4b88698e48.
> >
> > TEST=pkg/dds/test/control_web_server_starts_dds_with_dart_on_path_test.dart
> >
> > Change-Id: Id0f1dadd01d9202cbf7717f31393b43171cf3968
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373561
> > Auto-Submit: Ben Konyi <bkonyi@google.com>
> > Reviewed-by: Derek Xu <derekx@google.com>
> > Commit-Queue: Ben Konyi <bkonyi@google.com>
>
> Change-Id: I424c4b91b0b108ae4c9dffa0059ed90c918897e3
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373744
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Commit-Queue: Siva Annamalai <asiva@google.com>
> Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
Change-Id: Id7ddff5a80399203fb8058d84bc89fda2073da95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375000
Auto-Submit: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
This reverts commit 44d4451476.
Reason for revert: b/350443042
Original change's description:
> Reapply "[ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer"
>
> In the previous version of this change, if the user had 'dart' on their
> PATH and invoked 'dart compile js' (which spawns the VM service after
> compilation completes), the VM service would attempt to spawn DDS using
> './dart' as the executable path instead of 'dart'. This would result in
> DDS failing to start, causing the VM to print an error and hang.
>
> This updated change checks to see if the parent directory of
> `Platform.executable` is '.' and then verifies if './dart' exists or
> not. If it doesn't, 'dart' is likely on the user's PATH and should be
> used directly as the executable path.
>
> See https://github.com/dart-lang/sdk/issues/56087 for details.
>
> This reverts commit 4b88698e48.
>
> TEST=pkg/dds/test/control_web_server_starts_dds_with_dart_on_path_test.dart
>
> Change-Id: Id0f1dadd01d9202cbf7717f31393b43171cf3968
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373561
> Auto-Submit: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Derek Xu <derekx@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
Change-Id: I424c4b91b0b108ae4c9dffa0059ed90c918897e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373744
Reviewed-by: Siva Annamalai <asiva@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
In the previous version of this change, if the user had 'dart' on their
PATH and invoked 'dart compile js' (which spawns the VM service after
compilation completes), the VM service would attempt to spawn DDS using
'./dart' as the executable path instead of 'dart'. This would result in
DDS failing to start, causing the VM to print an error and hang.
This updated change checks to see if the parent directory of
`Platform.executable` is '.' and then verifies if './dart' exists or
not. If it doesn't, 'dart' is likely on the user's PATH and should be
used directly as the executable path.
See https://github.com/dart-lang/sdk/issues/56087 for details.
This reverts commit 4b88698e48.
TEST=pkg/dds/test/control_web_server_starts_dds_with_dart_on_path_test.dart
Change-Id: Id0f1dadd01d9202cbf7717f31393b43171cf3968
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373561
Auto-Submit: Ben Konyi <bkonyi@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 64d4689a78.
Reason for revert: Platform.executable doesn't return a path, just an executable name, which can cause breakages.
TEST=ci
Original change's description:
> [ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer
>
> TEST=pkg/dds/test/control_web_server_starts_dds_test.dart
>
> Change-Id: I2e51783592912e5a719685f2ab5e7537b7a59586
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366560
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Derek Xu <derekx@google.com>
Change-Id: I4ceaee4b5ca8f5557e90cd914ee69fe9aa5f85a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373381
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Siva Annamalai <asiva@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 change removes support for external strings from the VM along with
Dart_NewExternalLatin1String, Dart_NewExternalUTF16String and
Dart_IsExternalString Dart C API functions.
External strings are not used by the VM nor any known embedder, but
Dart VM was paying the maintenance and performance price for
the external string implementation classes.
TEST=ci
Change-Id: I094cd2d2b7ec0840e9f09e1ca9e5a7acd4e78c28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358760
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously, when taking a tear-off, a separate Context object was
allocated in order to capture receiver. Now, receiver is stored directly
in the Closure object in the 'context' field. This saves 1 object
allocation per tear-off and makes tear-offs cheaper compared to
explicit closures which can share context with other closures.
Benchmarks in AOT mode:
x64:
TearOff.NotInlined +40%
TearOff.NotInlined.InTry +43%
TearOff.Inlined.InTry +47%
arm64:
TearOff.NotInlined +27-43%
TearOff.NotInlined.InTry +29-43%
TearOff.Inlined.InTry +58-94%
arm64c:
TearOff.NotInlined +71%
TearOff.NotInlined.InTry +72%
TearOff.Inlined.InTry +96%
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/54808
Change-Id: I3ad95e8a8a4fc23f856bbc0fe238da58a9d25b8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350945
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
- Skip stdio_newline_test in AOT mode
- Fix capture_stdio_test and dds_stdout_stderr_history tests under the
observatory directory to account for the new line fix.
TEST=ci
Bug:54641
Change-Id: Ic5403ab30a1367e4ec9e6798545837813f8f1060
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346685
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Commit a52f2b9 which reworked awaiter stack unwinding and its
integration with debugger introduced the following regression:
it stopped treating `Future` listeners which had both `onValue`
and `onError` callbacks as catch all exception handlers. Only
listners with `onError` callback (those created with
`Future.onError`) were treated as a catch all handler.
This meant that debugger started to treat exceptions in the
code below as uncaught:
```
Future<void> foo() {
await 0;
throw '';
}
await foo().then(..., onError: (e, st) {
});
```
This change fixes this regression by checking if
`FutureListener.state & stateCatchError != 0` instead of
more narrow `FutureListener.state == stateCatchError` which
only detects listeners which only catch errors but do not
handle values. The new predicate matches
`FutureListener.handlesError`.
This relands 38e0046cad
with a fix to ensure that we correctly detect `onError`
callbacks which simply forward to a suspended async
function. We do this by marking FutureListener's that originate
from `await` using a bit in the state.
Fixes https://github.com/dart-lang/sdk/issues/53334
TEST=service/pause_on_unhandled_async_exceptions{_zones,}_test
Fixed: 53334
CoreLibraryReviewExempt: No fundamental changes to _FutureListener implementation, just additional bit to detect that this listener originates from await
Change-Id: I90385fc619cbb52925e075dd5c7b171a31ca4cab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323481
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit 38e0046cad.
Reason for revert: https://github.com/flutter/flutter/issues/133677
Original change's description:
> [vm] Treat Future.then(..., onError:...) as catch all handler
>
> Commit a52f2b9 which reworked awaiter stack unwinding and its
> integration with debugger introduced the following regression:
> it stopped treating `Future` listeners which had both `onValue`
> and `onError` callbacks as catch all exception handlers. Only
> listners with `onError` callback (those created with
> `Future.onError`) were treated as a catch all handler.
>
> This meant that debugger started to treat exceptions in the
> code below as uncaught:
>
> ```
> Future<void> foo() {
> await 0;
> throw '';
> }
>
> await foo().then(..., onError: (e, st) {
>
> });
> ```
>
> This change fixes this regression by checking if
> `FutureListener.state & stateCatchError != 0` instead of
> more narrow `FutureListener.state == stateCatchError` which
> only detects listeners which only catch errors but do not
> handle values. The new predicate matches
> `FutureListener.handlesError`.
>
> Fixes https://github.com/dart-lang/sdk/issues/53334
>
> TEST=service/pause_on_unhandled_async_exceptions_test
>
> Fixed: 53334
> Change-Id: I374114b7a7b2ef86b7ed6bf7d5e7cf71ba6054dc
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323280
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Slava Egorov <vegorov@google.com>
Change-Id: Id20a6929aac93511173c7467caee91e2488696ed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323429
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit a52f2b9 which reworked awaiter stack unwinding and its
integration with debugger introduced the following regression:
it stopped treating `Future` listeners which had both `onValue`
and `onError` callbacks as catch all exception handlers. Only
listners with `onError` callback (those created with
`Future.onError`) were treated as a catch all handler.
This meant that debugger started to treat exceptions in the
code below as uncaught:
```
Future<void> foo() {
await 0;
throw '';
}
await foo().then(..., onError: (e, st) {
});
```
This change fixes this regression by checking if
`FutureListener.state & stateCatchError != 0` instead of
more narrow `FutureListener.state == stateCatchError` which
only detects listeners which only catch errors but do not
handle values. The new predicate matches
`FutureListener.handlesError`.
Fixes https://github.com/dart-lang/sdk/issues/53334
TEST=service/pause_on_unhandled_async_exceptions_test
Fixed: 53334
Change-Id: I374114b7a7b2ef86b7ed6bf7d5e7cf71ba6054dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323280
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Ben Konyi