| commit | 02a09351edbded6c855418f904d2d4188d18aaaa | [log] [tgz] |
|---|---|---|
| author | Srujan Gaddam <srujzs@google.com> | Fri Dec 06 19:11:43 2024 +0000 |
| committer | dart-internal-monorepo <dart-internal-monorepo@dart-ci-internal.iam.gserviceaccount.com> | Fri Dec 06 11:13:34 2024 -0800 |
| tree | b1c1b5ade42d33d9626ddfc3b81ded7e8712cfb3 | |
| parent | 338a0d3ca03ac592a2e000a7535349af3b57e5c7 [diff] |
[linter] Change _isJsInteropType check to check for any instead of just userJsInteropType EraseNonJSInteropTypes erases extension types except for those that belong to dart:js_interop. It has an option 'keepUserInteropTypes' to determine whether to not erase user JS interop types *as well*. The code before this CL only checked for user interop types and not dart:js_interop types as well when that flag is enabled. Note that this doesn't lead to a bug anywhere and therefore there is no regression test. The only time we use this flag is to analyze the case where: 1. The right and left types are interop types where the erased left type (not keeping user interop types) is a subtype of the erased right type (not keeping user interop types). 2. The right is a user interop type. 3. The erased left type (keeping user interop types) is not a subtype of the erased right type (keeping user interop types). If 3 is true given the other conditions, then we lint. Since the right is a user interop type, the erased right type is just the right type. The only time this bug could make a difference is if the left type was a dart:js_interop type that we mistakenly erased. Since dart:js_interop types and their erased types can never be a subtype of a user interop type anyways, this bug could never have given a different value for 3 given the other conditions. This is therefore purely cleanup. Change-Id: I6aeaefd652e5f00094b5a89fda2d99b89a9bc516 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/399202 Commit-Queue: Phil Quitslund <pquitslund@google.com> Reviewed-by: Phil Quitslund <pquitslund@google.com> Auto-Submit: Srujan Gaddam <srujzs@google.com> https://dart.googlesource.com/sdk/+/58153b63e1246e4f366c008a3cca7d65f69a6d7e
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.