Unlike other calls from Dynamic Modules, dynamic calls cannot be
validated entirely at compile time. While we check that the selector
used matches a selector that was allowed (either because a method with
that selector name was exposed as dynamically callable or because the
selector was allowlisted during bytecode compilation), the compiler
doesn't know statically whether the target of the call is exposed.
In prior changes we modified the annotator to add a pragma indicating
whether a member is dynamically-callable or
implicitly-dynamically-callable. Here we use that information to set a
bit on functions and their corresponding dynamic invocation forwarders,
which is verified by the interpreter to make sure the dynamic call is
still allowed.
TEST=none yet - will be added in subsequent CL (see CL chain)
Bug: b/448095881
Change-Id: I27acb4e690a68e08fe1f1ca94e0d77cc7dc4d11e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498300
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Auto-Submit: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Also allows the --print-classes flag to be used in the AOT runtime if
dynamic modules are enabled and crashes with an appropriate error
message if class finalization fails when loading a member from bytecode.
TEST=co19/LibTest/math/Rectangle co19/LibTest/math/MutableRectangle
Cq-Include-Trybots: luci.dart.try:vm-dyn-linux-debug-x64-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try
Change-Id: I1921aa0189eb587cd4658c592a779be190af092e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495724
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
When compiled to WebAssembly, the Dart SDK needs access to external
host functions to implement regular expressions, stack traces, timers
and more. Currently, `dart2wasm` relies on `js_interop` definition to
implement these functions in JavaScript.
As discussed in https://github.com/dart-lang/sdk/issues/53884, an
alternative is to use `wasm:import` annotations to let an arbitrary
embedder that doesn't necessarily run in a JavaScript context inject
implementations for these host functions.
This would allow running `dart2wasm` apps by e.g.
- using a runtime like wasmtime and defining host functions in Rust.
- defining a wrapper module implementing required functions by
delegating to WASI definitions, and then using say `wasm-merge` to
run the app in any WASI-compatible runtime.
This prepares the `--standalone` flag on `dart2wasm` to do just that.
When enabled, the compiler uses a different SDK platform to use imports
instead of JS interop. For now, these platforms are almost identical:
I've ported the timer logic to use wasm imports as a demo, but the rest
is still based on existing patch files. We can revisit in subsequent
CLs to incrementally reduce `js_interop` dependencies before removing
that library from the `dart2wasm_standalone` target entirely.
Change-Id: I3f406afbf2dab65506094de5c3f4067f4db66f3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/486380
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@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 adds a target for running pkg/dynamic_modules/test/runner/main.dart from
an aot snapshot, useful when repeating runs for local iteration.
I'm not including it with other build targets or using it in the
test_matrix because each bot only runs this script once, so it doesn't
provide much savings there.
Change-Id: I20fe50a82d2a59aca6a0e697658b26b5b7da97c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480744
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Removed from `benchmarks/`, `runtime/`, `sdk/`, `tools/` and `utils/`.
(Leaving `tests/`, `pkg/` and `third_party/`.)
CoreLibraryReviewExempt: No real change.
Tested: No test changes for no real code changes.
Change-Id: Ieb42441457ca3d0ea4443dd153ee902ea33b28de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480241
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
In future this would allow us to automatically include libraries
specified in dynamic_interface.yaml into the compilation set as if
they were imported from Dart code.
Bug: b/452833638
TEST=ci
CoreLibraryReviewExempt: no API changes, only pragmas
Change-Id: If5705159148cd48f49f21485550747db1365767c
Cq-Include-Trybots: luci.dart.try:vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-linux-debug-x64-try,vm-dyn-mac-debug-arm64-try,vm-ffi-dyn-mac-debug-simarm64_arm64-try,vm-ffi-dyn-mac-release-simarm64_arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456401
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
- split the Dart CLI tool out of the VM into it's own embedder which
runs in AOT mode. The pure Dart VM executable is called 'dartvm' and
has no Dart CLI functionality in it
- the Dart CLI executable parses the CLI commands and invokes the rest
of the AOT tools in the same process, for the 'run' and 'test'
commands it execs a process which runs 'dartvm' to run
- 'dart hello.dart' execs the 'dartvm' process and runs 'hello.dart'
- the Dart CLI is not generated for ia32 as we are not shipping a
Dart SDK for ia32 anymore (support to execute the 'dartvm' for ia32
architecture is retained)
- the Dart CLI tool is not built in the internal Dart SDK builds
TEST=ci
Some performance improvement numbers
'dart format pkg/dartdev' goes from 1.17 secs to 0.22 secs
'dart doc pkg/dartdev' goes from 100.2 secs to 66.6 secs
'dart fix pkg/dartdev' goes from 19.3 secs to 14.5 secs
Change-Id: I66984a26cb2ab014b34dc1873f1f3d2884e13518
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364202
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Specify package_config.json when running DDC JIT snapshot training.
This allows the build to succeed in environments where the running
compiler would go searching for the package_config.json and find
one in some parent directory. This should fix local web engine
builds in Flutter which likely broke when the repo was migrated to a
pub workspace.
Change-Id: Ifb5b6357cbf40f04069020ab1b4aee099d0945ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/438602
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@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>
When dynamic modules are enabled, standalone VM can now run bytecode
binaries directly. Also, if --interpreter flag is specified, Dart
source is compiled to bytecode and interpreter is used to run it.
This will allow us to test VM service capabilities including
debugging and hot reload against the interpreter.
TEST=manual
Change-Id: Ibb5a67f4844485c4ed90b8a7568dc42fa552fcac
Cq-Include-Trybots: luci.dart.try:vm-aot-dyn-linux-debug-x64-try,vm-aot-dyn-linux-product-x64-try,vm-dyn-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436421
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Turns out that dart compile exe --depfile produces
depfile which does not work with ninja because
it uses absolute path to the output file
instead of using relative path.
So we can't use it directly and need to fix
depfile.
TEST=manually
Change-Id: I1aadfd5079cc38d392933f9afe333f63407bb295
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435680
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The name has always been annoying because it did not add strong typing. And now there aren't variants of the VM platform to distinguish.
Leave a copy at the old name to not immediately break illegal uses.
TEST=ci
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,flutter-frontend-try,flutter-linux-try
Change-Id: Ie76fa7f16940aa1ba8d582eb5197f0ae55dc8938
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429828
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Ryan Macnak <rmacnak@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>
This is a reland of commit 7ae1d75869
TEST=manual, no watchOS SDK on bots yet.
Original change's description:
> watchOS target os
>
> - add support for --os=watchos | --os=watchos_simulator
> - do not depend on perfetto if dart_support_perfetto is false
> - change the default value for dart_support_perfetto to !is_watchos
>
> To minimize changes and to avoid modifying third-party zlib BUILD file, is_watchos implies is_ios for now.
>
> TEST=manual, no watchOS SDK on bots yet.
>
> Cq-Include-Trybots: luci.dart.try:vm-mac-debug-arm64-try,vm-mac-release-arm64-try
> Change-Id: If2130068ef546162a07a9ba53f94b11ff25fb565
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415021
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
Cq-Include-Trybots: luci.dart.try:vm-mac-debug-arm64-try,vm-mac-release-arm64-try
Change-Id: I2b50f7eb4da173627aeb4833b88a08712b278d9f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425523
Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This reverts commit 7ae1d75869.
Reason for revert: breaks flutter build
Original change's description:
> watchOS target os
>
> - add support for --os=watchos | --os=watchos_simulator
> - do not depend on perfetto if dart_support_perfetto is false
> - change the default value for dart_support_perfetto to !is_watchos
>
> To minimize changes and to avoid modifying third-party zlib BUILD file, is_watchos implies is_ios for now.
>
> TEST=manual, no watchOS SDK on bots yet.
>
> Cq-Include-Trybots: luci.dart.try:vm-mac-debug-arm64-try,vm-mac-release-arm64-try
> Change-Id: If2130068ef546162a07a9ba53f94b11ff25fb565
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415021
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
Cq-Include-Trybots: luci.dart.try:vm-mac-debug-arm64-try,vm-mac-release-arm64-try
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I4bede9ede04ac3c533b8ff7ae2f1adbd84eb2397
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425262
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
- add support for --os=watchos | --os=watchos_simulator
- do not depend on perfetto if dart_support_perfetto is false
- change the default value for dart_support_perfetto to !is_watchos
To minimize changes and to avoid modifying third-party zlib BUILD file, is_watchos implies is_ios for now.
TEST=manual, no watchOS SDK on bots yet.
Cq-Include-Trybots: luci.dart.try:vm-mac-debug-arm64-try,vm-mac-release-arm64-try
Change-Id: If2130068ef546162a07a9ba53f94b11ff25fb565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415021
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ivan Inozemtsev <iinozemtsev@google.com>
This change adds a build target (see utils/analysis_server/BUILD.gn)
called 'analysis_server_aot'. This new target is _not_ included in the
Dart SDK (the create_sdk target). It's "opt-in" "for development."
The name of the new output file matches that of other snapshots (see
the dartdevc snapshots).
Then we do special work in the plugin manager if "we are AOT." An
analysis server running as AOT cannot spawn Isolates from a dart
source files; we must first compile a dart source file to AOT as well,
then we can spawn an Isolate to that AOT file.
_Then_ when we run pub, we can no longer rely on using
`Platform.executable`. `dartaotruntime pub get` is not a thing. We
must instead find the `dart` tool on disk. To do that, we copy some
complex discovery code from dartdev.
Work towards https://github.com/dart-lang/sdk/issues/53402
Work towards https://github.com/dart-lang/sdk/issues/53576
Work towards https://github.com/dart-lang/sdk/issues/50498
Manually tested:
* [+] analysis_server JIT snapshot works in IDE.
* [+] analysis_server JIT snapshot works in IDE, with a legacy
plugin (custom_lint).
* [+] analysis_server JIT snapshot works at commandline.
* [+] analysis_server AOT snapshot works in IDE.
* [x] analysis_server AOT snapshot works in IDE, with a legacy
plugin (custom_lint) - BROKEN. Need similar work that is done
for new plugins.
* [x] analysis_server AOT snapshot works at commandline - BROKEN.
I think a fair bit of refactoring is required in dartdev
lib/src/analysis_server.dart to use `VmInteropHandler.run` or
similar.
Change-Id: I53173c716fa2a763331ef524a96304f62165810e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417942
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This change adds pragmas which can be used in dart:* libraries to
specify classes and members which are used by the compiler
to implement certain language features. Compiler can insert
references to those classes and members when desugaring language
constructs, so dynamic module code can use these classes and members
implicitly even if they are private.
Previously, we required to specify these members in the
dynamic_interface.yaml before dynamic modules could use them.
However, this is cumbersome and error-prone.
Now, the following pragmas are recognized:
@pragma('dyn-module:language-impl:extendable')
@pragma('dyn-module:language-impl:can-be-overridden')
@pragma('dyn-module:language-impl:callable')
If dynamic interface yaml file is specified during compilation,
then classes/members annotated with these pragmas are treated as if
they are used in corresponding sections of dynamic_interface.yaml.
If dynamic interface yaml file is not specified, these pragmas
are ignored.
Bug: b/395992622
TEST=existing
CoreLibraryReviewExempt: no API changes, only adding pragmas.
Change-Id: I6606467fc5e5264a2565d7eb8e8baccc2eebea84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/418663
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
DDC does not depend on the stack trace mapper application being built
with unsound null safety so the unsound .dill files are unused.
Add the unsound .dill files to the `dart2js_bot` target because they
are dependencies of the `dart2js-hostasserts-linux-unsound` and
`dart2js-unit-linux-x64-release` configurations.
Update build step of `front-end-linux-release-x64` configuraton to
build the dart2js_bot target instead of relying on the unsound
dart2js .dill files through the `ddc_stable_test` target.
Change-Id: Ia29740b60f93d1d0b4a978ff5e37080e537401a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403382
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Ryan Macnak