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>
`package:native_assets_cli` has been split up and
`package:native_assets_builder` has been renamed.
Change-Id: Ic9d5c21bb3c7ecf7924fdee6b4281153ad37fac5
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-win-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425504
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This should make reload_sources_with_resident_compiler_test pass
consistently. This change re-enables the test on vm-win-release-x64, and
I will monitor its runs to see if it starts passing consistently.
CoreLibraryReviewExempt: This CL does not include any core library API
changes, only VM Service implementation changes in
sdk/lib/vmservice/running_isolates.dart.
Issue: https://github.com/dart-lang/sdk/issues/59909
Change-Id: I530da624aa926f148ba3ecdffbfc61b0e1048758
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410800
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Say you have a class method like this:
```
class Bar {
/*offset a*/ void /*offset b*/ qux() {
/*offset c*/ print("hello");
}
}
```
Lets also say that this method is run.
This will mark offset a and offset c as hits.
Offset b does not exist in coverage terms.
Now say you have an extension mehod like this:
```
extension Foo on Bar {
/*offset a*/ void /*offset b*/ baz() {
/*offset c*/ print("hello");
}
}
```
Lets also say that this method is also executed.
This will mark offset a and offset c as hits.
Offset b does not exist in coverage terms for this method.
Because extension methods are special though we create a special tearoff for
it. Lets say we didn't execute that one.
The tearoff method - before this CL - had offset b on positions that caused
the position to exist in coverage terms, and as the method wasn't executed
this would make it a miss.
This CL fixes the issue by setting the offsets on the tearoff that before
introduced offset b to offset a instead.
Change-Id: I3a5339135f3d76327624b35f04cc14afccaf487a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404563
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Also re-enables the tests on vm-win-release-x64 because having different
tests try to communicate with the same resident compiler in parallel was
definitely a source of flakiness, and I don't think there's any way of
knowing whether or not it was the only source of flakiness without
re-enabling it on the bots.
Issue: https://github.com/dart-lang/sdk/issues/59909
Change-Id: I831f32779e0946fb35811edaeaaa5ddb38e51d97
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404460
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
TEST=pkg/vm_service/test/reload_sources_with_resident_compiler_test.dart
and pkg/vm_service/test/breakpoint_resolution_after_reloading_with_resident_compiler_test.dart
CoreLibraryReviewExempt: This CL does not include any core library API
changes, only VM Service implementation changes within
sdk/lib/vmservice/.
Change-Id: Ibc99cd37439ddd8aca97fa7e18a5112cbfc3b4cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/401646
Reviewed-by: Ben Konyi <bkonyi@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>
To support expression evaluation on extension types - which are a static
thing and thus doesn't exist in the VM - on the CFE side we try to find
the available variables so that, for any variables that are found to be
extension types, we can treat them as such. This was introduced in
https://dart-review.googlesource.com/c/sdk/+/339900.
The problem is that this could accidentally _introduce_ new variables,
which would introduce new arguments to the created procedure causing
weird behavior in the VM as for instance seen in
https://github.com/dart-lang/sdk/issues/56911.
This CL makes sure to only set the type for already known variables (as
passed by the VM), thus not introducing new variables and fixing the
issues seen.
Fixes https://github.com/dart-lang/sdk/issues/56911
Change-Id: Ie8b8ae12438338e9c3d248d00cc5da81df5b8ece
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400120
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
TEST=pkg/vm_service/test/forward_compile_expression_error_from_external_client_with_dds_test.dart
and pkg/vm_service/test/forward_compile_expression_error_from_external_client_without_dds_test.dart
CoreLibraryReviewExempt: This CL does not include any core library API
changes, only VM Service implementation changes in
sdk/lib/vmservice/running_isolates.dart.
Fixes: https://github.com/dart-lang/sdk/issues/59603
Change-Id: I2b9edf69feb6149c80afe9fc753c73e069af0479
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397580
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
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>
Derek Xu