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 change includes an initial implementation of the new VM service
implementation based on `package:dart_runtime_service`, along with the
necessary plumbing to start it in place of the legacy VM service
implementation.
The entrypoint for the new VM service implementation is located in
dart_runtime_service_vm/bin/vm_service_entrypoint.dart, which is
compiled into AppJIT and AOT snapshots when the
`--include-experimental-vm-service` flag is provided to `build.py`. To run
the VM with the new VM service implementation, the
`--experimental-vm-service` flag must be provided.
Currently, the experimental VM service implementation supports:
- User specified ports
- Authentication code flags
- Enabling the HTTP server via SIGQUIT
- Some service protocol RPCs that don't require an isolate ID (e.g.,
`getVM`)
See go/dart-runtime-services-unification for more details.
TEST=Manual
CoreLibraryReviewExempt: dart:_vmservice is private
Change-Id: I4a58cd1fa0a386313baa3d5c5345720231279123
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/484820
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This change creates `pkg/dart_runtime_services/` with the initial
implementation of `package:dart_runtime_service`.
`package:dart_runtime_service` provides a simple interface to create
Dart services with common platform-agnostic features and behaviors,
while also allowing for configuration of custom service backends.
This initial implementation focuses on providing the initial shared
server functionality, including:
- Handlers for web socket and SSE connections
- Authentication code generation + validation
- Client management
- Initial RPC routing with two sample RPCs (getClientName, setClientName)
Change-Id: I1458269a5de7edd97120103a2c5fc2d0348eff31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478760
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Record only for definitions in libraries with a `package:` uri.
* Converts all the tests to be in packages.
* Bonus: This removes the uri-mapping in equality checks.
* These packages are added to the root pub workspace.
* For the dart2js tests we need to do some juggling to keep the
tests files in memory.
* Only support `package:` uris
* Removed all the `relativizeUri` code for file paths.
* Start emitting errors on non `package:` uris with a `@RecordUse()`
annotation.
Unrelated cleanups:
* We no longer support recording const instances in annotations, this
PR cleans up code in `kernel` and `type_flow`.
TEST=pkg/compiler/test/record_use/record_use_test.dart
TEST=pkg/dart2wasm/test/record_use_test.dart
TEST=pkg/vm/test/transformations/record_use_test.dart
Closes: https://github.com/dart-lang/native/issues/2891
Change-Id: I1bc6905291230375e185930d2c000700ac778f85
Cq-Include-Trybots: luci.dart.try:dart2wasm-asserts-linux-chrome-try,dart2wasm-asserts-minified-linux-d8-try,dart2wasm-linux-chrome-try,dart2wasm-linux-d8-try,dart2wasm-linux-firefox-try,dart2wasm-linux-jscm-chrome-try,dart2wasm-linux-optimized-jsc-try,pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try,dart2js-canary-linux-try,dart2js-hostasserts-linux-d8-try,dart2js-linux-chrome-try,dart2js-linux-firefox-try,dart2js-mac-chrome-try,dart2js-mac-safari-try,dart2js-minified-csp-linux-chrome-try,dart2js-minified-linux-d8-try,dart2js-unit-linux-x64-release-try,dart2js-win-chrome-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478920
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This package provides universal observability functionality for Dart
SDK CLI tooling. Any tool can opt-in into observability by starting
PerfWitnessServer. This will create a control socket in a fixed
location which can be then discovered by perf_witness recorder.
TEST=pkg/perf_witness/test
Change-Id: I698617a66fed42c6629c348d53964dae3f2148df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413683
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This roll moves `package:record_use` to the dart-lang/native repo.
Change-Id: I31183dc8b72272d7e94ed3031ca0b8bfca583e0d
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-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463662
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Michael Goderbauer <goderbauer@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 CL adds three new commands to `dart`:
```
Global
install Install a Dart CLI tool for global use.
installed List globally installed Dart CLI tools.
uninstall Remove a globally installed Dart CLI tool.
```
These commands are intended to replace `dart pub global` subcommands
while adding support for `hook/build.dart` and building packages in
AOT instead of running them with JIT.
Internal design doc: http://go/dart-install-cli.
Implementation details:
* The source of truth is the state of the file system. These commands
write and read directories, files, and symlinks.
* App bundles and symlinks are placed in `DART_DATA_HOME` as per
http://go/dart-data-home.
* On Unix systems we use symlinks and on Windows batchfiles to place
executables in the bin directory that point to an application
bundle. (These OS differences have been encapsulated in a single
class.)
* On Windows, when an application is running, trying to re-install it
will fail.
Test coverage:
* Installing from hosted, git, and local paths.
* Installing a package with hooks.
* Installing a package with hooks and user-defines.
* Surfacing build hook failures during install.
* Installing packages with conflicting executables names. This tests
`--overwrite` flag behavior.
* Installing a new or the same version, this should simply succeed.
* A warning is shown if the bin directory is not on the `PATH`.
* Running an installed app reports the correct exit code on exit.
* Listing all installed versions, including the versions not on
the`PATH`.
* Uninstalling, which uninstalls all versions.
* Re-installing while it is running.
* Uninstalling while it is running.
Out of scope for initial version:
* Saving the SDK version (to display in `dart installed`).
* Short-circuiting if re-installing an exactly installed version.
Bug: https://github.com/dart-lang/sdk/issues/60889
Change-Id: I8f3a60d26e013957ce6fd7f52e564bcaaff30509
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-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/441581
Reviewed-by: Sigurd Meldgaard <sigurdm@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Michael Goderbauer <goderbauer@google.com>
The directory location depends on the current OS:
- on Windows:
- `%LOCALAPPDATA%\Dart\<tool>`
- on Mac OS:
- `$HOME/Library/Application Support/Dart/<tool>`
- on Linux:
- `$XDG_STATE_HOME/Dart/<tool>` if `$XDG_STATE_HOME` is defined,
and
- `$HOME/.local/state/Dart/<tool>` otherwise.
The Dart data home can be overridden with the `DART_DATA_HOME`
environment variable.
This CL does not start using the new location yet.
Bug: https://github.com/dart-lang/sdk/issues/60922
Bug: https://github.com/dart-lang/sdk/issues/41560
Bug: https://github.com/flutter/flutter/issues/59430
Change-Id: I55e0ba610f8665ea3c9f053b36c943b097313046
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-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/440462
Reviewed-by: Alexander Thomas <athom@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Without their own pubspecs, they belong to `_` project from the root
`pubspec.yaml`. As a result, once we bump the SDK version, these
scripts cannot be executed with the checked in sdk.
Note: when we bump the SDK version we also must bump the version in
the root pubspec, otherwise unreleased language experiments break.
Change-Id: Ie2ec35865a5966d6801de832a4b6ad312a24d277
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436901
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
- Adds `dart_mcp` and `dart_mcp_server` as DEPS
- Build an AOT snapshot for the dart_mcp_server executable
- Add top level `mcp-server` command to dartdev (hidden).
- I also did add an `--experimental-mcp-server` flag which is required for this command to actually work. We had initially discussed not doing this due to complexity but I was able to keep it completely scoped to just this command. I can remove it if there are strong opinions though.
Change-Id: I737a5625507f69a904ccd1012682764eb360a2c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430900
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Jake Macdonald <jakemac@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>
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>
This is a reland of commit b9b77058a9
Original change's description:
> Migrate to use pub workspace
>
> Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
>
> All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
>
> All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
>
> Bug: https://github.com/dart-lang/sdk/issues/56220
> Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
> Tested: relies on CQ of existing tests. Should have no effect on functionality
> CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
> Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I29afabade2d2447dea05121cb87ff50bb21a4b76
Cq-Include-Trybots: luci.dart.try:flutter-linux-try,flutter-web-try
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `//
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415561
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This reverts commit b9b77058a9.
Revert "Add missing sample pubspec to workspace"
This reverts commit 892ea15ac7.
These seem to break the engine.
Change-Id: Ieee26deb7928c3869a1b6265326c3ce568ffe731
Tested: this is a revert.
CoreLibraryReviewExempt: this is a revert
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415582
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Use `pub get` to generate `.dart_tool/package_config.json` on gclient sync.
All pkg/ (and a few third_party) packages that are developed inside the sdk repo are included in the workspace from the root `pubspec.yaml`.
All dependencies that are pulled in via DEPS are added as path dependencies via `dependency_overrides` in the root `pubspec.yaml`.
Bug: https://github.com/dart-lang/sdk/issues/56220
Change-Id: I38c12b608c68da54c57821116cf9aa6696936746
Tested: relies on CQ of existing tests. Should have no effect on functionality
CoreLibraryReviewExempt: only core library change is adding a `// ignore:` comment. Should have no influence on functionality
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397164
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
kevmoo