So far this just builds the wasmer library, copies it into the sdk
directory, loads the library, and allows you to compile WASM modules.
You can't actually do anything with the modules yet.
Bug: https://github.com/dart-lang/sdk/issues/37882
Change-Id: I7d7cfe5721bbe38a6afe76f326518e714d236ed4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158367
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This also highlighted a couple of mistakes in the patch files for
dart:_internal and the test.
Change-Id: I60b4e7d5673d64f85a95108c9e03f9328249b9d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153021
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Capture content of request/response.
Changes about this cl:
1. The body of request will be written used by methods of `IOSink`. Each
operation will emit a single event on the same timeline task. Add() will
accept List<int> and write() works with strings. The data will remain
the same as what user has passed. With that being said, data coming from
add() will show a list of integers and a string representation if
write() is used.
2. The timeline of `HttpClientResponse` will be a child timeline of
corresponding `HttpClientRequest`. It will be recorded only if parent
request is recorded and logging flag is still set. If the flag is on
after the request is sent, the response will not be monitored.
3. `HttpClientResponse` is simply a stream. The timeline starts when
the response is received. But it is possible that users doesn't
read the content and close the program. In this case, timeline never
gets a proper close event. To have a close event, users has to call
listen().
4. This also fixes verify_http_time_line_test.dart. It was broken
and not checking correct events because of a typo.
Bug: https://github.com/dart-lang/sdk/issues/42952
Change-Id: I884db6405264a3ad9a03cecc8f5445dad4fb3e31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157567
Commit-Queue: Zichang Guo <zichangguo@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This change alone produces no diff when compiling the SDK, but
the type mismatch complicates the sound null safety performance
optimizations I am trying to make.
Change-Id: I1c41e8daf6fe5cab37a66ed7b5c8ccaa79fa1d73
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158723
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Auto-Submit: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
The documentation states the parameter must be an integer satisfying
`0 <= fractionDigits <= 20`. Given the existing implementation
passing `null` works like passing 0 but the VM and dart2js both throw
on `null` so it makes sense to enforce the precondition.
Change-Id: I71648b76dc5a4cece2f9b873bdcf58c2ff0563bc
Fixes: https://github.com/dart-lang/sdk/issues/42919
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157421
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
shutdown immediately after starting up
Running the VM with arguments that cause a quick failure _after_ the
service isolate is started could result in the VM service starting and
attempting to register a signal handler after the VM has started
shutting down. The open port held by the signal handler prevented the
message handler from shutting down, resulting in the main thread being
blocked on a monitor in ServiceIsolate::Shutdown.
Could be reproduced with the following commands:
$ rm out/DebugX64/dartdev.dart.snapshot
$ out/DebugX64/dart --observe hello_world.dart
Change-Id: I70ddff73c98151bd7eff22064a23f897b4d6299f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156923
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
connect to DDS without relying on a redirect.
Some WebSocket implementations (particularly dart:html's) don't follow
redirects and don't provide the user with the message returned by the
server.
This CL adds 'getWebSocketTarget' as an RPC which returns the
URI that should be used by the client to connect directly to the proper
web socket target. In addition, the "implicit-redirect" forwarding has
been removed.
Change-Id: Iaf88c965f6fedfa6f63c28a08860a3c80388797c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156485
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
an internal test on Fuchsia.
Change-Id: I1fc6124b7dbdd07a82d09daf5c870971e0c237de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156720
Commit-Queue: Mehmet Fidanboylu <mehmetf@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Both dlopen and LoadLibrary have caching behavior and only load the
dynamic library once into the DartVM, even with multiple isolates.
Change-Id: If16791baf28706c61acb1ecdae668485b264a373
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156682
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Creating a js object with `Object.create(null)` produces an empty
js object with no prototype. Calling methods attached to these
objects would result in a NPE since we assumed all objects would
have a valid `.__proto__`.
Discovered the error in some benchmark code. Created a new test
with the same patterns.
Change-Id: I1fd38893b0c90315b338c3b6a1b4981be1d64065
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156582
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
The previous version include the closing parenthesis in the link on the
dart doc site so it won't lead to the right place when clicked.
Switch to a markdown link instead of a raw URL to avoid ambiguity and
improve readability of the rendered doc.
Do some minor rephrasing of the rest of the comment to remove noise
words, format according to effective Dart.
Change-Id: I497cfeeeff0885eb34e798c469f95dc46f4a81f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156342
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Make sure Future.value constructor is inlined, so 'value == null'
test can be removed. Also, removes the implicit cast to FutureOr<T> on
all code paths and only leave a faster 'value as T' cast in case
value == null.
EmptyFutureTest benchmark in AOT/null safety mode on linux/x64: +11.62%
Change-Id: I56916d3a1f6a60e3fc9c50cd565db71aea6ab975
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155928
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
- Makes Future.wait a recognised function, and asserts its chained
future, _future is allocated at a known index in the context.
- Adds logic to locate, extract the chained future during lazy async
stack unwinding.
- Adds tests for the Future.wait async case.
- Minor consistency nits, comments.
This change is similar to a previous CL, adding Future.timeout support:
https://dart-review.googlesource.com/c/sdk/+/152328
Change-Id: I7439750968595d25d7bbac0068ad64fcc891e176
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155420
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The default behavior is controlled via a private configuration variable
settable by embedders (#_mayUseInsecureSocket). It is, by default,
configured to allow insecure connections. The domain configuration
itself is sent as a JSON encoded string which gets parsed once.
Embedders are expected to set these configurations before they run any
user code.
This is a re-work of https://dart-review.googlesource.com/c/sdk/+/142446
[dart:_http] Allow the embedder to prohibit HTTP traffic.
Change-Id: I4ccbd35da9ce25bf5f81ad4468111018d6af2f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154180
Commit-Queue: Mehmet Fidanboylu <mehmetf@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Towards #42395
These packages are used by benchmarks and need to be migrated to null
safety before stable.
Change-Id: I0b8a24f40384720343364795c60ddaede8fe0de4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156065
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Now the call in `dtest()` (directly above) is known to never return
so the type of `obj` can be promoted and there is no cast in the
return statement.
Change-Id: I9096dab87cfba5ea2289530070d0214974379ebc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155068
Reviewed-by: Mark Zhou <markzipan@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Also relands the followup CLs:
"Perform non-covariant checks when dynamically invoking callables."
"Use AreValidArguments so that names are checked as well."
Original description of first CL:
This change only affects compilation when running in non-precompiled
mode with --no-lazy-dispatchers enabled.
Instead of always compiling in non-covariant checks, even for closures
not called dynamically, remove the non-covariant checks from the closure
and instead do the non-covariant checks for dynamic calls during the
NoSuchMethodForCallStub fallback by calling
Function::DoArgumentTypesMatch.
Adds two overloads for Function::DoArgumentTypesMatch, one which takes a
function type argument vector and one which takes neither an
instantiator type argument vector or a function type argument vector.
For the versions that are not explicitly passed a type argument vector,
an appropriate one is constructed using the arguments. If there is not
enough information in the arguments, then we fall back to assuming the
empty type argument vector for the instantiator case and instantiating
to bounds in the function type argument case.
Fixes Function::DoArgumentTypesMatch to handle generic functions and to
check arguments appropriately according to the active null safety mode.
For generic functions, the provided or resulting function type vector
has non-covariant checks performed against the type parameter bounds.
This change uncovered one test that was incorrectly passing in strong
mode, see https://github.com/dart-lang/sdk/issues/42688 for details.
Original description of second CL:
The VM only does this when the callable function does not expect dynamic
invocations. Otherwise, performing the checks would be redundant, as the
function body already contains the appropriate non-covariant checks.
Third CL had no additional description.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-dartkb-linux-release-x64-try,vm-kernel-reload-linux-release-x64-try, vm-kernel-reload-rollback-linux-debug-x64-try
Bug: https://github.com/dart-lang/sdk/issues/40813
Change-Id: I1a3e9c1865103a8d716e1cad814267caffaaadf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154688
Reviewed-by: Martin Kustermann <kustermann@google.com>
c5a94db091 unintentionally changed the behavior of loadLibrary on a prefix that was already loaded from completing in a future turn of the message loop to completing in the same turn. Completing in the same turn is a legal behavior for loadLibrary, but consistently completing in a later turn helps to prevent code that works on accident.
Bug: https://github.com/dart-lang/sdk/issues/41974
Change-Id: Ib18d16f6b5517c882248f39b486e58e2635f24a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/155101
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Compiled output for sound null safety mode no longer needs to check
non-nullable arguments for null.
They can't be null since we no longer allow mixed opt-in/out libraries
when running with sound null safety.
Cleanup a repeated string in the SDK.
Change-Id: Ib7ae86f04660857957b4a7590bc5a7efd2c3fa04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154848
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Update the signature of _startMainIsolate to match _startIsolate with nullable List<String> args. Currently the flutter embedder passes null as the args, which triggers a null assertion with --null_assertions enabled.
See https://github.com/flutter/engine/blob/master/lib/ui/hooks.dart#L224 : the startMainIsolate function referred to is the
_startMainIsolate loaded from dart:isolate
https://github.com/flutter/flutter/issues/61770
Change-Id: Ida4af1f3cb1326d01e1a8d8c41199f44e3651d7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154833
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Jonah Williams <jonahwilliams@google.com>
(Assignment of libraries to loading units is already done in the kernel generation step.)
After compiling and before serializing, we walk the program and for each Code we assign its Instructions, CodeSourceMap and CompressedStackMap to the loading unit of that Code's defining library. Deduplication may cause Instructions, CodeSourceMaps and CompressedStackMaps to belong to more than one loading unit; in this case the objects are assigned to the root loading unit. Later they can be more precisely assigned to the dominating loading unit.
All objects except some Instructions, CodeSourceMaps and CompressedStackMaps belong to the root loading unit's snapshot. This snapshot is written like an unsplit snapshot, except that when serializing Code, we will write a reference to a stub or null when the Code's Instructions, CodeSourceMap or CompressedStackMap belongs to a non-root loading unit. The snapshots of non-root loading units contain these deferred objects and references to the corresponding Code objects to patch. The types of objects we defer (Instructions, CodeSourceMaps and CompressedStackMaps) usually represent 70+% of the snapshot size.
Bare instructions mode must be disabled when splitting because we cannot have PC-relative calls between loading units. Later we can re-enable this for calls within loading units.
Broken: Compactor probably crashes we can now have an unbounded number of image pages and the compactor assumes a fixed number.
Embedder's guide:
At compile-time, gen_snapshot should be passed --loading_unit_manifest with a path, which will enable splitting and output a mapping from loading unit ids to snapshot output paths.
At runtime, sometime during isolate startup, an embedder should call Dart_SetDeferredLoadHandler, probably near an existing call to Dart_SetLibraryTagHandler. The callback is given a loading unit id, and should eventually call Dart_DeferredLoadComplete[Error].
Bug: https://github.com/dart-lang/sdk/issues/41974
Change-Id: Ib597eb87c8cd634416d5ee1f00629c5550aebb00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152427
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit bc4cb123a8.
Reason for revert: breaks crossword simarm tests https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-precomp-linux-debug-simarm_x64/2619
Original change's description:
> Reland "[ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process"
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
>
> This reverts commit 3849b5061c.
>
> Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,asiva@google.com
Change-Id: I649d94c668417f2edbfd7039fa5c876e10dc32fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154800
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
This reverts commit 3849b5061c.
Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit 556f0fb5c8 and fixes merge conflict.
Revert "[vm] Perform non-covariant checks when dynamically invoking callables." as a collateral.
This reverts commit 7a6287bb92.
Revert "[vm] Use AreValidArguments so that names are checked as well." as a collateral
This reverts commit 90c683018f.
Change-Id: Iee2c5e91c39d19dca7a1e640c103443c95e6c4f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154705
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This reverts commit ffe258d2d4.
Reason for revert: Failures on bots
Original change's description:
> [ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
>
> Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: Idb1d24a4524bdc3ccfb199a82710f3c0d9db539a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154702
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This change only affects compilation when running in non-precompiled
mode with --no-lazy-dispatchers enabled.
Instead of always compiling in non-covariant checks, even for closures
not called dynamically, remove the non-covariant checks from the closure
and instead do the non-covariant checks for dynamic calls during the
NoSuchMethodForCallStub fallback by calling
Function::DoArgumentTypesMatch.
Adds two overloads for Function::DoArgumentTypesMatch, one which takes a
function type argument vector and one which takes neither an
instantiator type argument vector or a function type argument vector.
For the versions that are not explicitly passed a type argument vector,
an appropriate one is constructed using the arguments. If there is not
enough information in the arguments, then we fall back to assuming the
empty type argument vector for the instantiator case and instantiating
to bounds in the function type argument case.
Fixes Function::DoArgumentTypesMatch to handle generic functions and to
check arguments appropriately according to the active null safety mode.
For generic functions, the provided or resulting function type vector
has non-covariant checks performed against the type parameter bounds.
This change uncovered one test that was incorrectly passing in strong
mode, see https://github.com/dart-lang/sdk/issues/42688 for details.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-dartkb-linux-release-x64-try
Change-Id: I5030a46b356778448b51a243f16406eacf1c04bf
Bug: https://github.com/dart-lang/sdk/issues/40813
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153202
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This makes both compilers report a compile-time error when importing dart:mirrors.
Change-Id: I23360b87ee31fba36fe7c111cee1987aa2d50638
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154622
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
