The previous three scripts had some redundancies:
* Both the flutter/flutter analyzing script and the flutter/packages
analyzing script checked out flutter/flutter. Combining them saves
several minutes.
* The script that analyzed flutter/engine was pointing to the old
engine repo, which was archived months ago. In pointing the script
to the new sources at flutter/flutter, this would introduce another
instance of cloning flutter/flutter. Combining this with the other
scripts saves several minutes.
The only other little changes to the code are the introduction of
more echo commands, more `pushd`/`popd` vs `cd`, and isolating the
three tasks into functions for readability.
Change-Id: I08414d824c25075a8810b1aa0cc299c64328abbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432881
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Use a combination of gen_snapshot's new ability to generate dylibs directly and the copy of llvm in buildtools to avoid using XCode, which is not available in shards.
Add definitions for debug builders now that they can complete without timing out.
Cq-Include-Trybots: luci.dart.try:vm-aot-mac-product-arm64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try
Change-Id: I79924128f11aafab4cd74ea6e9ab5848c64557da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431700
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Currently, the configuration code only has a boolean option, 'use-elf'
for specifying the output format for gen_snapshot. If false, then the
output format is assumed to be assembly.
Add a new GenSnapshotFormat enum and replace the old 'use-elf' option
with a new 'gen-snapshot-format' option. The new enum has two getters:
* snapshotType returns the appropriate string to pass to gen_snapshot
via the '--snapshot-type' option.
* fileOption returns the name of the option used to specify the
output path for the given format.
In addition, make it so the Configuration only has a non-null
genSnapshotFormat field if the compiler is Compiler.dartkp to avoid
spurious differences in Configurations that are created with different
GenSnapshotFormat values when the configurations in question don't
actually call gen_snapshot.
TEST=pkg/smith/test/configuration_test.dart (and the CI in general)
Change-Id: I7f17dc8d3a1bb6d4bf57750bc5ef4a16b8a78c11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429980
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Switch build to use Clang. This somewhat degrades FFI testing, but reduces build time by roughly half or one hour.
Cq-Include-Trybots: luci.dart.try:pkg-win-release-arm64-try,vm-aot-win-debug-arm64-try,vm-aot-win-release-arm64-try,vm-win-debug-arm64-try,vm-win-release-arm64-try
Change-Id: Ie267942e99934312b228cfadcd6d5b8477f855c8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429421
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Add builder definitions for ASAN on Mac and Windows.
Combine reload and reload rollback into one builder.
Change-Id: If464f82d1d8c0560f4e7f1e341f59e5f29301a30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427303
Reviewed-by: Alexander Aprelev <aam@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 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>
The hostasserts and non-hostasserts filesets do not differ significantly
and can be merged for ease of maintenance. The cost of copying extra
files is small compared to building, and we currently lack the
granularity to see meaningful savings in builds if we keep them separate.
Change-Id: If8e3dd1013f60b05dabb104c632abd7a1638fe1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417947
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Currently we have 3 different string types (JS Strings, OneByteString
and TwoByteString)s. There's some advantages to this, mainly that
if strings are used purely inside Dart we have more control over
optimizing them. But it does come with some issues
* Operations on mixture of strings are slow
* We get JS strings from outside (in DevTools e.g. websocket messages)
* Any kind of DOM interaction requires copying strings
* Regular expression matches can result in O(N*N) instead of O(N)
* Encoding of string literals/constants is terrible, high size overhead
* ...
Now that there's a standardized way to access JS strings (via
the `js-string` builtin spec) and this standard is finalized and
enabled in Chrome & Firefox it makes sense for us to switch to it.
It reduces app size:
* Smaller size: hello world -25%, flute -5.5%
* Faster startup
The performance changes are nuanced, some workloads will improve
significantly, some workloads will regress.
Improvements will come especially in cases where
strings are concatenated (due to JS not actually allocating new
strings in this case). That impacts e.g. string interpolations,
string buffer, json-to-string encoding, ...
Regressions will come especially for cases where we have to
construct strings from bytes (e.g. in utf8 decoder, utf8+json
decoder) - mainly due to having to go through an intermediary
`WasmArray<WasmI16>` to allocate strings. Also in cases where we
access individual char codes from the strings.
There's some follow-up improvements we can do, but it's better to
not iterate on this CL even longer but get it landed.
This CL will make the benchmarking system use
`--require-js-string-builtin` as well as most of test CI
(in `pkg/dart2wasm/tool/compile_benchmark`)
Though we run some configurations via overriding with
`--no-require-js-string-builtin`
(in `tools/bots/test_matrix.json`)
Issue https://github.com/flutter/flutter/issues/159400#issuecomment-2538593980
Issue https://github.com/dart-lang/sdk/issues/59699
TEST=ci
Change-Id: I238ac65efe092de569da870f23134f889ac929f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392903
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The file will contain a JS expression that evaluates to a boolean.
If it (at runtime) evalutes to
* `true` it means that all required features are supported by the JS
environment and the dart2wasm-compiled app can be used
* `false` it means some features were not present in the JS
environment and the dart2wasm-compiled app shouldn't be used,
instead a dart2js fallback may be used
We introduce this mechanism to allow users, at compilation time, to tell
dart2wasm to take advantage of new spec features and allow the runtime
to self-detect whether they are available and fallback to dart2js if
not.
The first feature we introduce (already in this PR) is
`--require-js-string-builtin` that will tell dart2wasm it can assume the
`js-string` builtin is available (and emit corresponding `*.support.js`
code to detect it).
If the flag was passed, we take advantage of the `js-string` import
mechanism for string constants that doesn't require emitting them in the
mjs file (which significantly reduces code size and improves startup
time - compared with emitting JS strings in the mjs file).
We enable `--require-js-string-builtin` on one CI configuration for
testing that if we don't use any polyfill, the imports of the builtin
functions as well as magical utf8-encoded wasm imports work.
We also use a template mechanism to generate `*.mjs` as the code
becomes more readable (e.g. to conditionally include the js string
polyfill)
Issue https://github.com/dart-lang/sdk/issues/59951
Change-Id: Ic7e7818a2d5269095935022941352beeb9fed731
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/408781
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The optimized builders run with binaryen which by default strips static symbols
(in all -Ox modes). So we'll pass `--no-strip-wasm` to `dart compile
wasm` in order to keep the static symbols.
This makes stack traces have the symbols in them which will make tests
that rely on that more likely to work.
Change-Id: I9e0eab8c4ec50ef3a7208551d04a80e9ffa009e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/406241
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Fixes https://ci.chromium.org/ui/p/dart/builders/ci.sandbox/pkg-win-release-arm64/3781.
With new split the steps are distributed roughly like this:
```
$ RBE=0 tools/build.py -mrelease -ax64 gen_snapshot
[982/982] LINK ./gen_snapshot
The build took 39.285 seconds
$ RBE=0 tools/build.py -mrelease -ax64 runtime/bin:dart runtime/bin:run_vm_tests
[1392/1392] LINK ./run_vm_tests
The build took 97.936 seconds
$ RBE=0 tools/build.py -mrelease -ax64 runtime
[1223/1223] ACTION //utils/kernel-service:frontend_server_aot_product(//build/toolchain/linux:clang_x64)
The build took 97.168 seconds
$ RBE=0 tools/build.py -mrelease -ax64 create_sdk ddc_stable_test
[402/402] COPY gen/dart2js_aot_product.dart.snapshot dart-sdk/bin/snapshots/dart2js_aot.dart.snapshot
The build took 100.373 seconds
```
Also add Ryan to the OWNERS_INFRA.
Change-Id: Ibbf1a13ccd33d7bcb366ac864b05e960e5d73b8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404201
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The weekly bot currently fails because the weak suite no longer have
dart2js_platform_unsound.dill available. This CL fixes that.
Change-Id: I2a8e71b6b8ce1ec9a9aa3d9456245c217f8ac26d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404102
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jens Johansen <jensj@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>
Sam Rawlins