| commit | fdbc911caebdd5d1b8ecd0fd6dbf6d0b579c9686 | [log] [tgz] |
|---|---|---|
| author | Vyacheslav Egorov <vegorov@google.com> | Fri Jan 10 00:24:29 2025 -0800 |
| committer | dart-internal-monorepo <dart-internal-monorepo@dart-ci-internal.iam.gserviceaccount.com> | Fri Jan 17 09:05:47 2025 -0800 |
| tree | 21adf0bac030b0b317ba41648c9c544a8b5feb20 | |
| parent | 7f09f38a4d09402d292dfdcc3a4434f6adb525da [diff] |
[vm/compiler] Prune SSA during construction using liveness Only insert Phi at JoinEntry and Parameter at CatchBlockEntry if corresponding variable is alive into the block. This keeps insertion consistent with environment pruning logic employed by RenameRecursive: which prunes dead variables out environments when entering the block based on contents of the live_in set. Previously we would insert Parameter instructions for dead variables which lead to an incorrect (unsound) set of catch entry moves generated by the backend due to an inconsistency between Parameter insertion and environment pruning logic and the fact that catch entry moves generator would simply ignore all moves if the source of the move was an optimized_out (aka constant_dead) marker. The following situation was possible: if the variable was assigned inside the try and partially alive inside of it (e.g. we had blocks where it was alive and blocks where it was not) then we would end up inserting Parameter for it, but some of the exceptional edges (corresponding to blocks where the variable was dead) would carry optimized_out value into that Parameter. However `CatchEntryMoveFor` would not record these moves leading to uninitialized garbage arriving on those exceptional edges instead. Note that Phis were not susceptible to the same issue as Parameters because regalloc / backend would not treat optimized_out value specially. This change converts silent treatment of optimized_out in the catch entry moves generation into a release assert instead. Reviewing other uses of constant_dead in the compiler revealed a bug in canonicalization rule for `o.runtimeType` which did not take exceptional edges into account. We add a regression test for that and fix that issue as well. Fixes https://github.com/dart-lang/sdk/issues/59822 TEST=vm/dart/regress_59822,vm/dart/regress_runtime_type_in_trycatch Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-linux-product-x64-try,vm-aot-linux-release-arm64-try,vm-aot-linux-release-simarm_x64-try,vm-aot-linux-release-x64-try Change-Id: I8dc397cb98d84048a1791b9dd6baa7586a2688c6 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403583 Reviewed-by: Alexander Aprelev <aam@google.com> Commit-Queue: Slava Egorov <vegorov@google.com> https://dart.googlesource.com/sdk/+/4bcd8c2b8ce56756dbe7dd762af7f9322a777402
Monorepo is:
With depot_tools installed and on your path, create a directory for your monorepo checkout and run these commands to create a gclient solution in that directory:
mkdir monorepo cd monorepo gclient config --unmanaged https://dart.googlesource.com/monorepo gclient sync -D
This gives you a checkout in the monorepo directory that contains:
monorepo/ DEPS - the DEPS used for this gclient checkout commits.json - the pinned commits for Dart, flutter/engine, and flutter/flutter tools/ - scripts used to create monorepo DEPS engine/src/ - the flutter/buildroot repo flutter/ - the flutter/engine repo out/ - the build directory, where Flutter engine builds are created third_party/ - Flutter dependencies checked out by DEPS dart/ - the Dart SDK checkout. third_party - Dart dependencies, also used by Flutter flutter/ - the flutter/flutter repo
Flutter's instructions for building the engine are at Compiling the engine
They can be followed closely, with a few changes:
goma_ctl ensure_start is sufficient.Example build commands that work on linux:
MONOREPO_PATH=$PWD if [[ ! $PATH =~ (^|:)$MONOREPO_PATH/flutter/bin(:|$) ]]; then PATH=$MONOREPO_PATH/flutter/bin:$PATH fi export GOMA_DIR=$(dirname $(command -v gclient))/.cipd_bin goma_ctl ensure_start pushd engine/src flutter/tools/gn --goma --no-prebuilt-dart-sdk --unoptimized --full-dart-sdk autoninja -C out/host_debug_unopt popd
The Flutter commands used to build and run apps will use the locally built Flutter engine and Dart SDK, instead of the one downloaded by the Flutter tool, if the --local-engine option is provided.
For example, to build and run the Flutter spinning square sample on the web platform,
MONOREPO_PATH=$PWD cd flutter/examples/layers flutter --local-engine=host_debug_unopt \ -d chrome run widgets/spinning_square.dart cd $MONOREPO_PATH
To build for desktop, specify the desktop platform device in flutter run as -d macos or -d linux or -d windows. You may also need to run the command
flutter create --platforms=windows,macos,linux
on existing apps, such as sample apps. New apps created with flutter create already include these support files. Details of desktop support are at Desktop Support for Flutter
Tests in the Flutter source tree can be run with the flutter test command, run in the directory of a package containing tests. For example:
MONOREPO_PATH=$PWD cd flutter/packages/flutter flutter test --local-engine=host_debug_unopt cd $MONOREPO_PATH
Please file an issue or email the dart-engprod team with any problems with or questions about using monorepo.
We will update this documentation to address them.
flutter commands may download the engine and Dart SDK files for the configured channel, even though they will be using the local engine and its SDK.gclient sync needs to be run in an administrator session, because some installed dependencies create symlinks.