This CL copies and modifies hash map and set base class `_HashBase`
currently shared with the VM, to improve types of the fields.
The Wasm struct for hash map and set objects was previously:
(type $_HashBase (sub $Object (struct
(field $field0 i32)
(field $field1 (mut i32))
(field $field2 (mut (ref null $Object))) ;; _index
(field $field3 (mut i64))
(field $field4 (mut (ref $Object))) ;; _data
(field $field5 (mut i64))
(field $field6 (mut i64)))))
Now:
(type $_HashBase (sub $Object (struct
(field $field0 i32)
(field $field1 (mut i32))
(field $field2 (mut (ref $Array<WasmI32>))) ;; _index
(field $field3 (mut i64))
(field $field4 (mut (ref $Array<Object?>))) ;; _data
(field $field5 (mut i64))
(field $field6 (mut i64)))))
_index and _data fields are now non-nullable Wasm arrays. This removes
downcasts and one layer of indirection when accessing the elements. In
addition, when accessing `_index` this eliminates unboxing the integers.
Fixes#54961.
Change-Id: I4e6bd5129c7c57f5716ccb23e46060d73ffca217
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354843
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The hot reload runner currently only supports d8, but I plan to add support for Chrome and VM execution.
Notable changes:
* Creates `package:reload_test` with helpers for running this suite.
* Updates the module loader with D8-specific branches and hooks for hot reload/restart.
* Exposes DDC runtime variables via a `HotReloadTestRuntime` API.
* Ports constant equality hot restart tests from webdev/dwds (validated to fail if either cache-clearing mechanism fails).
* Partially rolls DDC's d8 preamble forward (towards dart2js's).
* Wraps D8's timer implementation with custom timeout logic to better match Chrome's timing semantics when executing with native JS async.
Tests for the framework and matrix updates will be added in an upcoming change.
Change-Id: I2773b29f464cfd0330e4c653c05e117ae150b4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350021
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Fixes https://github.com/dart-lang/sdk/issues/55024
The patch files for these operators return a bool, whereas
the public API returns a JSBoolean. Since there's only one
possible return type, we should make them return bool for
convenience. Boolean conversion is also inexpensive on
dart2wasm, so that shouldn't be an issue.
Also adds helpers to operator_test to make sure any JS values
are converted before they're compared, adding additional type
checking through the conversion.
CoreLibraryReviewExempt: Fixes type mismatch in backend-specific library.
Change-Id: I7ff2e334e817e6e7d7d8d5091a4e5d570a496b03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354702
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
- Rephrase docs on JS types
- JS -> JavaScript where applicable
- “This” and “that” expanded to refer to the thing
- Add docs to undocumented members
- Rephrase some docs to be clearer and more explicit
- Move warnings to format that dartdoc can display specially
- Add warnings to every single member that should have it
- e.g. -> like
- Makes similar docs consistent
- Removes library declarations per style guide. Regenerates
expectations to handle the change.
CoreLibraryReviewExempt: Backend-specific library. Docs only.
Change-Id: I246f8c20d594741149766e5a76bb186debf54ded
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352977
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Mention error zones in the docs for `runZoned`. We expect most of these
use cases to be handled by `runZonedGuarded`, but specifying an error
handler on the `ZoneSpecification` can still trigger this behavior.
Expand the phrasing from mentioning that some futures might not complete
to describe the specific reason - errors cannot cross zone boundaries
with different error zones, so specifically Futures which complete as
errors are at risk of not completing in the parent zone.
R=lrn@google.com
CoreLibraryReviewExempt: Doc changes only.
Change-Id: I8759dfb6da48463e0bb33a000943d60a4dd3d5ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348043
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Gives the constructor optional parameters for providing
more information that can be used in the `toString` message,
and the `stackTrace` getter.
Makes the `iterable.wait` and `record.wait` extension methods
provide such information, so that the `toString` will always
contain the text of *one* of the errors.
(No issue, problem with logging was brought up in chat.)
Change-Id: I5f9a20ad0af0c64a2e7ff3cdb56f187a5cf5a3ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353080
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The web platforms used to invent a spurious stack trace when reading
`Error.stackTrace` before the object was thrown.
They now return `null` instead, if there is no underlying JS error object,
matching specified behavior.
Fixed bugs in async error throwing in dart2wasm:
* `throw` in an async function did not set the stack trace on an error.
Now calls `Error._throw` instead of just a direct Wasm "throw".
* `async*` functions did not capture the stack trace of a throw
that ended the function body, which means it called
`StreamController.addError` with only one argument.
That then resused the stack trace from an `Error` throw instead
of the correct stack trace.
Added tests.
Change-Id: I1d9fa8d9e18076a7fe28254b60b950866cd550a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354021
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Similar to dart2js --trust-primitives, with --omit-bounds-checks
(implied by -O4) we omit bounds checks in standard library list and
typed array indexing methods, such as `operator []` and `[]=`.
For now this flag does not omit range checks in functions like
`setRange` and `setAll`:
- Functions like `setRange` do more work than functions like `[]` and
`[]=`, and bounds checks are a smaller part of the whole operation.
- For the same reason, and also because they either don't return any
values or have to return boxed (i.e. `getRange` needs to return an
`Iterator`), inlining them is not as crucial as inlining an
`Uint8List.[]` implementation (which avoids boxing when inlined).
Closes#54962.
Tested: dart2wasm change with small refactoring in VM, tested with existing tests.
Change-Id: Idd5f11ee85c7e67ba8de621b305c413e7e7f7ebb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353982
Reviewed-by: Martin Kustermann <kustermann@google.com>
* We migrate the `dart:developer` implementation of dart2js to
static interop.
* We make dart2wasm use the same implementation as dart2js.
Closes https://github.com/dart-lang/sdk/issues/54991
Change-Id: I7873edc7e804500c8eca878367d9045c98a1c2e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354101
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
- Also adds the public exception APIs to dart:_macros which were missing.
Change-Id: If08bcb8bc60b91eaf08a02140c6d310e7c2e51f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Currently the dds process is being launched from dartdev and
this causes problems when the dartdev commands 'run' and 'test'
are implemented by spawning child processes (this is needed
to make dartdev an AOT snapshot).
This CL attempts to lauch dds from the service isolate code.
TEST=ci
Change-Id: Iad00a17473a630659f15a5c73be0f5385ea35bdd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350688
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Currently hash code for a closure is the hash code of it's runtime type.
This causes a lot hash collisions in some apps and cause performance
issues.
With this patch we now use captured objects in closures when calculating
hash codes.
The hash codes are now:
- For tear-offs:
mix(receiver hash, closure runtime type hash)
- For instantiations:
mix(instantiated closure hash,
hashes of captured types)
Note that an instantiation can be of a tear-off, in which case
"instantiated closure hash" will calculate the tear-off hash as above.
- For others (function literals, static functions), the hash is the
identity hash.
Fixes#54912.
CoreLibraryReviewExempt: Mark private corelib function as entry-point in Wasm
Change-Id: I6a123fdc690237f543bb8bf832f0f8119d013a55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353162
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
If a target `_Future` is chained to another source `_Future`,
then it's because the target will complete with the same
result as the source future. Instead of keeping both
alive with a listener on the source which completes the target,
instead the target moves all its listeners to be directly on
the source, and keeps a link to the source in case more listeners
are added later.
The idea is that most futures are unreferenced after they have
had their first listener, so the target future has a chance
to be GC'ed.
If the target future has `.ignore()` called, and has no listener,
then the source completing with an error should not cause the
error to be uncaught. Without the optimization, the source would
have had a listener, and the target would ignore the error.
To simulate that, the source now gets a copy of the target's
`_ignoreUnhandledErrors` flag.
This is still not precisely the same as it would be without the
optimization. If *two* target futures are chained to the same source,
and only one of targes has `.ignore()` called, then this
implementation will make the uncaught error not be reported,
where it technically should.
(An alternative would be to *not* use chaining for futures
with `ignore()` called on them. But those are precisely futures
that are likely to be GC'able, because someone has already said
that they don't care if the future complete with errors.)
Fixes#54943
Bug: https://github.com/dart-lang/sdk/issues/54943
Change-Id: I0dbb4919ce2ea612d66539862fa0eb188aab8287
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352908
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This code is no longer used now that the new runtime types are always
enabled.
Change-Id: I0c7d627199a10e023d5d1afa581812b360e9a0f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/344609
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
There is a performance impact in:
`stdout.lineTerminator = "\r\n";`
For small writes (<100 chars), the performance loss is lost in the noise of the `write` system call.
For writes of ~500 chars, the performance is about half of that without line terminator translation. But, on a M2 Mac laptop, ~80M characters can be written per second.
Bug: https://github.com/dart-lang/sdk/issues/53161
Change-Id: Icfa0f981dcf6edb856d8aac5e0e270bc0148d498
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326761
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Commit-Queue: Brian Quinlan <bquinlan@google.com>
Improve the handling of code where the async flow forks:
e.g. for `fut.whenComplete(c.complete)` we might proceed
unwinding through awaiters of `c.future` and forget about the
future returned from `whenComplete`. This happens because
we choose to present result of the unwinding as a single
stack and not a tree. In this situation the error will only
propagate into that future and whether or not the error will be
handled depends on that future alone.
As part of this change also start respecting ignored bit on
futures without listeners.
TEST=pkg/vm_service/test/pause_on_unhandled_async_exceptions7_test.dart
CoreLibraryReviewExempt: Comment only changes to core library
Change-Id: I27b689ab07a725e8faa8d91cf40e88ebc8c441a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352904
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This CL adds @pragma('vm:awaiter-link') in various places in
Stream implementation to facilitate unwinding and expands
async unwinding logic with more information about
Stream internals.
At the same time be more conservative when checking if an
exception thrown from async method handled: failing to unwind
the stack fully creates situations when we incorrectly report
caught exceptions as uncaught, which frustrates users.
To distinguish stream subscriptions with and without error
handlers we add a state bit. Otherwise, it looks like all
subscriptions have error handlers because if no error
handler is installed we eagerly install error handler forwarding
the error to `Zone.handleUncaughtError`.
Fixes https://github.com/dart-lang/sdk/issues/53334
Fixes https://github.com/dart-lang/sdk/issues/54788
Fixes https://github.com/dart-lang/sdk/issues/47985
TEST=runtime/vm/dart/awaiter_stacks/stream_methods_test.dart,pkg/vm_service/test/pause_on_unhandled_async_exceptions6_test.dart,pkg/vm_service/test/pause_on_unhandled_async_exceptions7_test.dart
CoreLibraryReviewExempt: No behavioral change. Async changes reviewed by lrhn@
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-dwarf-linux-product-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try
Change-Id: Ic51f926867092dd0adbe801b753f57c357c7ace2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322720
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The APIs mentioned above are `addHttpClientProfilingData` and
`getHttpClientProfilingData`.
This CL also makes it so that profiling information recorded using
`addHttpClientProfilingData` is included in dart:io service extension
responses.
TEST= pkg/vm_service/test/get_http_profile_test.dart
Change-Id: I892a7a8485369bb92cbb0c086b93498bcec25d5f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341440
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Some preparation for deleting all the old type system code.
Change-Id: I9319064100ce19a4122612c36781c7e4a71094aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352724
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
We can't generate a virtual call to `Object.==` in generated code as
`Object.==` may not be added to the dispatch table, even with
`@pragma(wasm:entry-point)`.
Instead this adds a top-level `_runtimeTypeEquals` function that calls
`==` on the `_Type` argument. Effectively this forces adding `_Type.==`
to the dispatch table and calls it virtually.
Fixes#54926.
Change-Id: Ice3306ed00f66c8abedb3ef11b58c15296457eb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352900
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
The linked README(https://github.com/skeeto/hash-prospector#two-round-functions) has been updated with these parameters that result in a significantly lower bias that other projects have also began adapting.
For context, this function is used internally by `Object.hashAllUnordered`.
Change-Id: I7ca042196bbfdb5abdb28f8d6d9cbca69d21fb2b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Auto-Submit: Parker Lougheed <parlough@gmail.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
These can't be deprecated for a while, at least not until 'dart:html' itself is.
In the mean time, we can at least discourage usage of it and direct developers to more appropriate, long-term solutions.
Contributes to https://github.com/dart-lang/sdk/issues/54852
CoreLibraryReviewExempt: Documentation only change that directs developers to more specific, performant, or flexible solutions.
Change-Id: I9d099a49909673f8af23eab480fdd225e56bcab2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351961
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The dart closures for the then/onError callbacks we use on a JS promise
will not flow back into dart. There's therefore no reason to use the
very heavyweight `allowInterop` mechanism.
This makes (after [0]) asynchronous calls to JS from Dart more than 2x
as fast.
This also aligns the `promiseToFuture` implementation with the extension on
`JSPromise` (see sdk/lib/_internal/wasm/lib/js_interop_patch.dart)
modulo the fact that the API doesn't work on interop types but Dart
types and needs therefore the full JS<->Dart conversion.
=> Maybe it would make sense to deprecate `promiseToFuture` / not offer it
in dart2wasm and make users use instead the extension on `JSPromise`
instead?
[0] https://dart-review.googlesource.com/c/sdk/+/352520
Change-Id: Ibc80bf083e7ec817f000257d6995108954060277
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352521
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Also cleans up some wording and better explains all the possible
features of the annotation.
CoreLibraryReviewExempt: Docs for backend-specific library.
Change-Id: Id5f3e1ea09d2ceaf9f727eb7885b38319b978dd6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352441
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This significantly speeds up certain operations as it avoids calling
complex closure equality logic in the hashmap operations.
See also [0] regarding us leaking those closures.
[0] https://github.com/dart-lang/sdk/issues/54908
Change-Id: I046063884b88fbe53bc3cb397b0087693c9b928a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352520
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
CoreLibraryReviewExempt: Only touches JS core library documentation.
Change-Id: I7d7f0a2b646f95de8340e9e77d8207cd99c9a1b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351940
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
There should be no need to use polymorphic `.codeUnitAt()` calls in
the common case: comparing OneByteString with OneByteString, etc
This increases e.g. LongStringCompare.* benchmarks by 600+%
Change-Id: I1b7b2b53f35237d1ddc1c177c01728629a4acf40
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352020
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
* Use `WasmArray<>`s in string interoplation expressions
* Use `WasmArray<>`s in string buffer implementation
* Avoid making OneByteString+JSString imply TwoByteString
This also increases performance significantly, e.g.
JsonObjectRoundTrip & StringBuffer by 40% in -O4 and even more
speedup in -O2
Change-Id: I25485a6c532c3afed7d92943b6de4d1452930606
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352000
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
For getting the address of `Struct` fields and `Array` elements
it would be useful to access the `_typedDataBase` field in these
'wrappers' in a unified way.
This CL makes `Array` extend `_Compound`.
Since `Array` is not a `SizedNativeType`, the implements clauses
for `Struct` and `Union` are moved to these classes.
Moreover, any references to 'compound' which only apply to struct or
union are updated.
TEST=test/ffi
Bug: https://github.com/dart-lang/sdk/issues/44589
Bug: https://github.com/dart-lang/sdk/issues/54739
Bug: https://github.com/dart-lang/sdk/issues/41237
CoreLibraryReviewExempt: No API change, only refactoring.
Change-Id: Ib9d8bccd4872df04bcc67731e4052f826ab70af4
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-ubsan-linux-release-x64-try,vm-win-debug-arm64-try,vm-win-debug-x64-try,vm-win-release-ia32-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350960
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
dart2js already had an external function in foreign_helper called
JS_FALSE. This function is completely opaque until it is lowered to the
constant value `false` in SSA, so one can write `if (JS_FALSE())` in
order to ensure that the guarded code is treated as live and compiled,
but eventually tree-shaken and omitted from SSA and codegen.
This CL adds a JS_TRUE counterpart for completeness, and exposes both
JS_TRUE and JS_FALSE through package:dart2js_runtime_metrics.
Change-Id: I9b375fa37ada1b65fb9183902bb295e05fa6b8c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349704
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
This CL:
* adds empty dart:_dart2js_only and dart:_ddc_only libraries for use in
conditional imports,
* updates pkg/dart2js_runtime_metrics to use the new libraries rather
than dart:_dart2js_runtime_metrics and dart:js,
* and removes some unnecessary libraries, including VM-specific
implementations in pkg/dart2js_runtime_metrics and the DDC
implementation of dart:_dart2js_runtime_metrics.
Change-Id: I9500aa303fa5ad8aba0e1d413f69957c268f3f11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350681
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This is a fix to not include a null assert when it's
possible the value was null.
Fixes https://github.com/dart-lang/sdk/issues/49972
CoreLibraryReviewExempt: bug fix only affecting html library implementation
Change-Id: I26e6ebf3dc2d1ea3f9f458a32f519c5235e6d273
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350982
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
CoreLibraryReviewExempt: just changing web libraries
changekind:NO_CODE_CHANGE
Change-Id: Idc8ab1865f43f33c3ab0824142b38fa715b1579b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350520
Auto-Submit: Kevin Moore <kevmoo@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
