Mark server_connection_api_test and server_connection_vm_service_test as Slow, Pass in pkg/pkg.status to prevent false-positive timeouts on slower/loaded builders.
TAG=agy
CONV=2fddba4d-da91-4fcd-923a-faee680c5b4e
Change-Id: Ic4fa73242c3c64d517294d9a8fb1fec5e0423380
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507660
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: Ben Konyi <bkonyi@google.com>
Reviewed in https://dart-review.googlesource.com/c/sdk/+/497583
[dartpad] Part 1: Protocol and Scaffolding
This sets up folders for `package:dartpad` and `package:dartpad_worker`,
R=athom@google.com, sigurdm@google.com
including:
* `OWNERS` files,
* Protocol definition,
* Exceptions, and,
* Virtual file system utilities.
[dartpad] Part 2: HotReloadCompiler
Adds the hot reload compiler logic to dartpad_worker.
This is models on dartdevc with `--reload-last-accepted-kernel` and
`--reload-delta-kernel` options. I don't think this does an incremental
compilation, instead it does a modular compilation. Meaning, we can have
a huge collection of precompiled DDC modules and the compiler just gets
a DDC outline/summary dill files for these modules. But on the other hand
the actual code that is compiled will be recompiled on every compile()
call.
This is very important for flutter_web.js / flutter_web.dill where the
precompiled DDC modules is around 60 MB in total. The fact that
package:flutter is precompiled into flutter_web.js is critical for
compilation performance for small dartpad-style example apps.
The downside is that unlike incremental compilation with _frontendserver_,
if the user were to install package:http and use it in the app they are
compiling then every `compile()` call will recompile `package:http`.
Where as with _frontendserver_ we'd be able to invalidate specific files,
and only those would be recompiled.
This leaves future work to either:
* (A) Add support for modular compilation to _frontendserver_, such that
we can do incremental compilation without having to first compile all
of `package:flutter`.
* (B) Refactor compilation strategy implemented here, to leverage
modular further. We could for example compile all dependencies from
`PUB_CACHE` into a `pub_cache_outline.dill` inside the dartpad worker.
Then recompilation would only touch the user-code. Granted this is
still less than ideal.
At the moment the lack of incremental compilation is not a blocker,
current dartpad doesn't have incremental compilation, but granted it also
only supported a single file. This dartpad environment will support
multiple files, but adding many files will result in poor performance
until we refactor and figure out how to do incremental compilation.
Hence, why we shouldn't block progress waiting for incremental compilation
to work.
R=nshahan@google.com
[dartpad] Part 3: Pub execution wrapper
Adds the internal wrapper for executing pub commands inside the
worker's virtual file system.
R=sigurdm@google.com
[dartpad] Part 4: Language Server wrapper
Adds the internal wrapper for spawning and communicating with the
Dart LSP inside the DartPad worker.
R=scheglov@google.com
[dartpad] Part 5: DartPad Worker
Implements the main worker entrypoint, RPC message handling. The
`bin/worker.dart` is what will be compiled to WASM and will run as a
_Web Worker_.
R=sigurdm@google.com
[dartpad] Part 6: DartPad Client library
The public-facing `dartpad` library that developers use to embed
the compilation environment in their web applications.
This finishes `package:dartpad`featuring:
* `DartPad.create()`, which creates a _Web Worker_ running the compiled
`pkg/dartpad_worker/bin/worker.dart`, and returns a `DartPad` instance
wrapping RPC calls into the _Web Worker_.
* `Sandbox.createIFrame()` which creates a _sandboxed iframe_ containing
precompiled DDC modules from the SDK assets and `sandbox.js` for
wrapping `ddc_module_loader.js` with an RPC interface. This returns a
`Sandbox` instance wrapping RPC calls into the _sandboxed iframe_,
making it easy to load modules, run library entrypoints (main()),
initiate hot-reload, or launch a flutter app.
This is an initial API design that works. There are minor inconsistencies
and improvements that we should do. But I propose that we do so in
follow-up PRs.
R=sigurdm@google.com
[dartpad] Part 7: Build Targets
Adds a `dartpad` target to the Dart SDK, which produces:
```
out/ReleaseX64/dartpad/
├── dart
│ ├── dart_sdk.js.map
│ ├── sdk.js
│ └── sdk.tar
├── ddc_module_loader.js
├── sandbox.js
├── worker.loader.js
├── worker.mjs
├── worker.support.js
├── worker.wasm
└── worker.wasm.map
```
The `dartpad/` output folder is intended to be used as `assetBaseUrl` in
client libraries provided in `package:dartpad`. And the `dartpad/dart/`
folder is intended to be used as `sdkLocation`. These files are not
intended to be distributed along side the normal Dart SDK, instead we'll
publish them on a CDN and let people use `package:dartpad` to point at
these files. If they want to self-host everything, they can copy from our
CDN or rebuild the files using a local Dart SDK checkout.
These files are also necessary for testing, to ensure that we have proper
integration tests for `pkg/dartpad_worker/`. As we will want to publish
these files on a CDN the actual compiled size in release-mode matters,
thus, we have enabled wasm optimizations steps in this mode.
R=rmacnak@google.com
[dartpad] Part 8: Tests for `package:dartpad` and `pkg/dartpad_worker/`.
We have 3 kinds of tests:
* Unit tests (vm, browser or both),
* Worker tests (vm and browser),
* Integration tests (browser-only).
As the Dart SDK test runner simply executes `*_test.dart` files with
`dart` and doesn't support compiling tests to the browser, launching and
running tests in the browser, we employ `dart test` to run tests. We do
this by having `pkg/dartpad_worker/dart_test.yaml` specify that
`dart test` should look for files names `test_*.dart`, and we then create
`pkg/dartpad_worker/test/ci_test.dart´ to be a single test that simply
runs `dart test` as a subprocess. Thus, the only test file triggered by
Dart SDK test runner is `ci_test.dart`, and if you locally run `dart test`
this will run the individual `test_*.dart` files.
While this hack to use `dart test` isn't ideal it gives everyone a decent
work flow. And saves us from having to invent complex test harness for
`pkg/dartpad_worker/`.
**Worker tests** defined in `test/dart/worker/` and `test/flutter/worker/`
are all imported into `test_dart_worker.dart` and
`test_flutter_worker.dart` to reduce test compilation time. These have a
non-trivial compilation time because the worker is running in the test
process. This allows testing on VM, which can be easier to debug.
**Integration tests** unlike _worker tests_ launch the worker compiled by
the `dartpad` build target in a _Web Worker_. This has less compilation
overhead for the individual tests, but involves more setup, and can be
a bit harder to debug.
Both worker and integration tests employ `test/asset_server/` which serves
assets built by the `dartpad` build target, and serves as a pub-server for
tests. It also serves assets built by `tool/setup_local_flutter.dart`
which creates flutter assets, though this is not intended to run as part
of CI, since we do not have a Flutter checkout available. Thus, for the
time being flutter testing is local only. Maybe, later we'll move this
script to another repository.
R=sigurdm@google.com
Cq-Include-Trybots: luci.dart.try:pkg-linux-release-try,pkg-win-release-try
Change-Id: I3a99939ec5217b9f3a855fc5b9ad9699047d02cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507321
Commit-Queue: Jonas Jensen <jonasfj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This CL migrates the `dwds` and `dwds_test_common` packages into the Dart SDK
repository.
Key Changes:
- Monorepo Compliance: Updated the pubspecs to align with the SDK pub workspace setup.
- Excluded `pkg/dwds_test_common/fixtures/` from `package_deps.dart`.
- Updated pkg to status to skip `dwds/test/integration/*` & `dwds_test_common/fixtures/*` until DWDS migration is complete.
- Remove package `build_daemon` from DWDS' `pubspec.yaml` as it's not approved for SDK env.
- Added `@skip_package_deps_validation` to the following files to ignore import checks for package:build_daemon: `server.dart`, `utilities.dart`, `context.dart`.
- Created `pkg/dwds/lib/src/utilities/test_path_utils.dart` to fix path resolution failures in tests (ie. `build_script_test.dart` and `ensure_version_test.dart`).
Testing:
- All tests passing locally.
- CI try bots are green.
Design Doc: http://goto.google.com/migrating-webdev and http://goto.google.com/migrating-dwds
Fixes https://github.com/dart-lang/sdk/issues/62100
Fixes https://github.com/dart-lang/sdk/issues/62101
Fixes https://github.com/dart-lang/sdk/issues/62102
Fixes https://github.com/dart-lang/sdk/issues/62103
Cq-Include-Trybots: luci.dart.try:pkg-win-release-try,pkg-win-release-arm64-try,pkg-mac-release-try,pkg-mac-release-arm64-try,pkg-linux-release-try,pkg-linux-release-arm64-try,pkg-linux-debug-try
Change-Id: I6130be8b7e0b42fbbf81b26a4950a2c4282e3a48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494660
Commit-Queue: Jessy Yameogo <yjessy@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This CL migrates the `frontend_server_client` package into the Dart SDK
repository.
Key Changes:
- Migration: Moved source code and tests into `pkg/frontend_server_client`.
- Monorepo Compliance: Updated the pubspec to align with the SDK pub workspace setup.
- Linting: Adopts `package:dart_flutter_team_lints` for analysis options and fixes associated linting errors.
- Path Resolution: Resolved package configuration and script path issues encountered in local and CI environments; see the [Workspace Tests Fixes](https://docs.google.com/document/d/1UdiRqP19qYgj-ItxDfqXSdUU6CGimiyK3BmdvjtTEyw/edit?pli=1&tab=t.0#heading=h.xfm1ezicaoik) in the design doc for implementation details.
Testing:
- All tests passing locally.
- CI try bots are green.
Design Doc: http://goto.google.com/migrating-webdev
Cq-Include-Trybots: luci.dart.try:pkg-win-release-try,pkg-win-release-arm64-try,pkg-mac-release-try,pkg-mac-release-arm64-try,pkg-linux-release-try,pkg-linux-release-arm64-try,pkg-linux-debug-try
Change-Id: Id44a701107d626df5fcd21d724980243981c7958
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461200
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jessy Yameogo <yjessy@google.com>
This reverts commit c2095cb347.
Reason for revert: These changes are blocking the Dart SDK -> Flutter roll because they cause some Fuchsia tests to fail.
Original change's description:
> Reland "[VM/Service] Shut down the VM immediately after the VM Service fails to start during VM initialization"
>
> This reverts commit d510876d9e.
>
> Reason for revert: g3 and Golem have been made compatible with this CL.
> See b/409535026 and
> https://chrome-internal-review.googlesource.com/c/golem/+/8345341.
>
> TEST=pkg/vm_service/test/failure_to_start_vm_service_after_vm_is_initialized_test,
> pkg/vm_service/test/failure_to_start_vm_service_during_vm_initialization_test
>
> Original change's description:
> > Revert "[VM/Service] Shut down the VM immediately after the VM Service fails to start during VM initialization"
> >
> > This reverts commit 56ccf437e6.
> >
> > Reason for revert: b/409535026
> >
> > TEST=ci
> >
> > Original change's description:
> > > [VM/Service] Shut down the VM immediately after the VM Service fails to start during VM initialization
> > >
> > > TEST=pkg/vm_service/test/failure_to_start_vm_service_after_vm_is_initialized_test,
> > > pkg/vm_service/test/failure_to_start_vm_service_during_vm_initialization_test
> > >
> > > Fixes: https://github.com/dart-lang/sdk/issues/60256
> > > Change-Id: I0543ab26e5721a4048136f27e8f4429bef04920f
> > > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416300
> > > Commit-Queue: Derek Xu <derekx@google.com>
> > > Reviewed-by: Ben Konyi <bkonyi@google.com>
> >
> > Change-Id: I61eb42f0f00ad97e95e3ebf19990fe75d2d416aa
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421622
> > Reviewed-by: Derek Xu <derekx@google.com>
> > Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
> > Reviewed-by: Ben Konyi <bkonyi@google.com>
>
> Change-Id: Ieba880b7b298e491055c3f6049bab6772b1f8aa3
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434960
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I03b2371728de91e4e20008a879280c1ccab4d07c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435540
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Derek Xu <derekx@google.com>
This reverts commit d510876d9e.
Reason for revert: g3 and Golem have been made compatible with this CL.
See b/409535026 and
https://chrome-internal-review.googlesource.com/c/golem/+/8345341.
TEST=pkg/vm_service/test/failure_to_start_vm_service_after_vm_is_initialized_test,
pkg/vm_service/test/failure_to_start_vm_service_during_vm_initialization_test
Original change's description:
> Revert "[VM/Service] Shut down the VM immediately after the VM Service fails to start during VM initialization"
>
> This reverts commit 56ccf437e6.
>
> Reason for revert: b/409535026
>
> TEST=ci
>
> Original change's description:
> > [VM/Service] Shut down the VM immediately after the VM Service fails to start during VM initialization
> >
> > TEST=pkg/vm_service/test/failure_to_start_vm_service_after_vm_is_initialized_test,
> > pkg/vm_service/test/failure_to_start_vm_service_during_vm_initialization_test
> >
> > Fixes: https://github.com/dart-lang/sdk/issues/60256
> > Change-Id: I0543ab26e5721a4048136f27e8f4429bef04920f
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416300
> > Commit-Queue: Derek Xu <derekx@google.com>
> > Reviewed-by: Ben Konyi <bkonyi@google.com>
>
> Change-Id: I61eb42f0f00ad97e95e3ebf19990fe75d2d416aa
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421622
> Reviewed-by: Derek Xu <derekx@google.com>
> Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
Change-Id: Ieba880b7b298e491055c3f6049bab6772b1f8aa3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434960
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
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>
Ben Konyi