TEST=pkg/vm_service/test/id_zone_deletion_on_client_disconnect_with_dds_test.dart,
pkg/vm_service/test/id_zone_deletion_on_client_disconnect_without_dds_test.dart,
CI
Issue: https://github.com/dart-lang/sdk/issues/55869
CoreLibraryReviewExempt: This CL does not include any core library API
changes, only VM Service implementation changes in
sdk/lib/vmservice/client.dart and
sdk/lib/vmservice/running_isolates.dart.
Change-Id: I32a72ade89b858519c61b5124adbeafb835c3d61
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381520
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Before this CL, becase of optimizations, coverage of some of these goes
away, making coverage unreliable.
I believe this fixes the issues for "regular" runs (at least it seems to
be stable on the CFE coverage tests).
If setting `--optimization-counter-threshold=-1` there'll still be
trouble though and we would have to also insert these calls in the start
of FunctionBody and the start of FieldInitializer for it to produce the
same results.
TEST=pkg/vm_service/test/coverage_instance_call_after_optimization_test.dart,pkg/vm_service/test/coverage_static_call_after_optimization_test.dart
Bug: https://github.com/dart-lang/sdk/issues/42061
Bug: https://github.com/dart-lang/sdk/issues/55959
Bug: https://github.com/dart-lang/sdk/issues/56018
Change-Id: I34947f0d4b123e52ce67b71a195782d31e4bda16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370501
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Slava Egorov <vegorov@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>
- 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>
This CL introduces an alternative way to calculate scopes for
expression evaluations. Currently the previous method is kept as well.
What this does is that it:
* Finds all nodes that match the offset and uri. (Ideally there's only
one, but that's not always the case --- it's the case for less than
60% of cases in the test added actually).
* Calculate the scope along the way.
* Return the scopes of all the found nodes that offset.
A test that asks for ~all file offsets in the dill files in the sdk and
compares the result with the scope the binary serialization computes is
added.
A single point can't always be found (for all dills in the sdk
only ~58.93% returns a single result), but for each query the wanted
scope is among the results returned.
For the non-outline dills in the sdk, between ~87.93% and ~94.52% of
the results are either a single result or multiple results with the
same actual scope in all of them.
Note that the test asks for ~all offsets, not just "debuggable" or
"stopable" offsets (which will likely vary depending on the vm/web
backend etc) --- likely the percentage will be higher for those points
though.
When this returns multiple results one can likely be picked by the
client based on information it has about names of variables in scope
etc.
Note that the test is rather slow, on my machine with the platforms
available there it makes 3,908,181 queries in ~3.5 minutes.
(Which corresponds to roughly 18,610 per second or under 0.06 ms per
query on average though, so it doesn't seem like a concert for actually
using it.)
Change-Id: I40b5360fcd935c70629543737e89a787de36ca16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332204
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Many tests under `pkg`, like `pkg/js_ast` and `pkg/analyzer_cli` are
meant to run as unit tests in the Dart VM. These were also being run in
dart2js and causing flakiness because they took a long time to build on
our CQ.
Locally some of these tests compile in under 5s, but we see the
compile-time vary among the bots a lot. I've observed cases close to 30s
and some that reach the 1-minute timeout cutoff. Flakiness data show
that this is happening between 5-7% of the runs, especially on linux
bots.
This CL stops running these tests on the dart2js configuration by
changing which subset of the `pkg` suite is provided to dart2js. It also
adjusts the .status file to skip a few suites for convenience on local
testing only. This allows developers locally to run `test.py -n... pkg`
without worrying about filtering out skipped suites.
Addendum: after discussions on the CL we decided not to cmpletely drop
coverage of js_ast tests on JS to ensure it can be used in browser
environments in the future. To support this we made made the tests
cheaper by removing the dependency on package:test. They will now only
be run in a single configuration, which is all we need for this purpose.
We can reevaluate and remove this if we continue to see timeouts.
Change-Id: Idf0dbdd37e412ef71ba117ec979cb1e52585c431
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330704
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This package contains the logic for building native assets.
This package is the backend that invokes toplevel `build.dart` scripts.
For more info on these scripts see https://github.com/dart-lang/native.
This is a separate package so that dartdev and flutter_tools can reuse
the same logic without flutter_tools having to import dartdev.
Some design decisions:
* We don't yet have `build_dependencies`, so we use the ordinary
dependency graph for ordering of native assets builds. (If there is
a cycle we refuse to run.)
Bug: https://github.com/dart-lang/pub/issues/3794
* Builds are cached based on all the configuration provided by the
caller. Environment variables are ignored in caching. This CL also
contains a unit test that invokes the build by not passing through
environment variables. However, for Windows we need to pass through
at least `SYSTEMROOT` for MSVC to run correctly. So we might need
to further explore if we can/want to lock env variables down.
Bug: https://github.com/dart-lang/native/issues/32
Bug: https://github.com/dart-lang/native/issues/33
Run tests:
```
dart tools/generate_package_config.dart && \
tools/test.py -n unittest-asserts-release-linux pkg/native_assets_builder
```
Bug: https://github.com/dart-lang/sdk/issues/50565
Change-Id: I133052d7195373e87d20924d61e1e96e3d34ce8f
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/300203
Reviewed-by: Liam Appelbe <liama@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Hossein Yousefi <yousefi@google.com>
The purpose of the CL is to enable re-use of the mmap support in dart2js
in other tools (e.g. package:heapsnapshot & package:kernel).
There's a small refactoring to remove zero-termination logic out of the
general mmap support.
Change-Id: I7a9889acea43d5ce0ab1eb10dcefbfa74c44bf93
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279348
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Derek Xu