| commit | 315fc327cec255838090513f6ee286cb75638554 | [log] [tgz] |
|---|---|---|
| author | Paul Berry <paulberry@google.com> | Tue Feb 20 20:21:48 2024 +0000 |
| committer | dart-internal-monorepo <dart-internal-monorepo@dart-ci-internal.iam.gserviceaccount.com> | Tue Feb 20 12:23:15 2024 -0800 |
| tree | 90503637af5ce6ecac51601cd76595d03ce5ff84 | |
| parent | 5ee832b731d1835bfac5343c94a6d0c907cdbd2e [diff] |
Fix analyzer handling of record literal type inference. This CL contains several small bug fixes: - The context is only used for type inference if it is a record type with the same shape as the record literal. Previously, if the context was a record type with a different shape than the record literal, the analyzer would attempt to do an approximate match (using the context from any matching named fields, and from all the positional fields that were in common between the context and the literal). At first glance, it might seem like this would only matter for erroneous code (since record shape mismatches typically lead to compile-time errors). But if the context arises from a local variable promotion, then a mismatch doesn't lead to a compile-time error; it simply leads to a demotion. So the difference is observable for non-erroneous code. - If one of the fields is implicitly downcast from `dynamic`, the static type of the field's expression remains `dynamic`. This makes the behavior of dynamic downcasts inside field literals consistent with all other implicit dynamic downcasts. - If one of the fields is implicitly downcast from `dynamic`, the downcast is made to the greatest closure of the context. Previously, the downcast was made to the context itself, which meant that it was possible to create static types containing the unknown type, violating one of the key assumptions of the Dart type system. - If one of the fields has a static type of `dynamic`, and `dynamic` is a subtype of the greatest closure of the context (e.g. because the context is `Object?`), no dynamic downcast is performed. Previously, a dynamic downcast _was_ performed, meaning that the static type of the resulting record literal would have `dynamic` in a spot where `Object?` should be. This brings the analyzer behavior into line with the spec and the front end, with one minor exception: - When the front end uses the greatest closure of the context to implicitly downcast a field from dynamic, it uses a modified greatest closure algorithm where covariant instances of `_` are replaced with `dynamic` instead of `Object?`. The front end's behavior in this rare case doesn't agree with the spec; I'll address this in a future CL. Change-Id: Ib1ab7ee4d0f63a152480704e2c0d5332446a613c Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350983 Reviewed-by: Bob Nystrom <rnystrom@google.com> Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Commit-Queue: Paul Berry <paulberry@google.com> https://dart.googlesource.com/sdk/+/32ab5476882c072af446d948737531101dafdd3e
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.