Adds more descriptive ArgumentErrors to flutter driver deserialization
methods for commands and finders.
Also adds support for the normal defaults to the deserialization
handlers (can revert this if you like, but it helps when interacting
with flutter driver as a client so that it is more similar to how the
API works).
The tests aren't completely exhaustive as that would get very verbose,
but they do cover a variety of use cases.
Fixes https://github.com/flutter/flutter/issues/172127
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
<!-- start_original_pr_link -->
Reverts: flutter/flutter#169451
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: matanlurey
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: Broke a number of post-submit tests
(ios_app_extension, packages_autoroller).
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: mosuem
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {matanlurey}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
Reland after #169357.
Switch Flutter to use pub workspaces as a preparation to unpin selected
packages.
Assumptions:
1. No packages in this repository are published to pub.dev --> We can
use `any` dependencies in most local pubspecs, as the global constraint
defines the version. An exception are the packages used outside of this
repo with an `sdk` dependency, namely `flutter_localizations`,
`flutter_test`, and `flutter`.
2. The "universes" `{flutter_tools}` and `{flutter,
flutter_localizations, flutter_goldens}` can use different packages
versions, as they are not resolved together. --> We do not need to
upgrade them in sync, we can first do one "universe", then the other.
Based on these assumptions, we use
https://github.com/mosuem/pubspec_merger.dart to merge all packages in
the `flutter` universe into a top-level pub workspace.
The `flutter` and `flutter_tools` workspaces being separate also ensures
that changes to `flutter` will not inadvertently break `flutter_tools`,
with not-so-nice consequences for our users which would be unable to run
`flutter upgrade`.
There is a third "top-level" pubspec besides `./pubspec.yaml` and
`packages/flutter_tools/pubspec.yaml`, namely
`packages/flutter_tools/.../widget_preview_scaffold/pubspec.yaml`. This
is an artifact due to it living under `flutter_tools`, so it can't be
part of the `./pubspec.yaml` workspace. Moving it would be a larger
change, and out of the scope of this PR.
This required a rewrite of the update-packages tool, but the main
functionality stays the same, as well as the argument names, to ensure a
seamless transition.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
Reland after #169357.
Switch Flutter to use pub workspaces as a preparation to unpin selected
packages.
Assumptions:
1. No packages in this repository are published to pub.dev --> We can
use `any` dependencies in most local pubspecs, as the global constraint
defines the version. An exception are the packages used outside of this
repo with an `sdk` dependency, namely `flutter_localizations`,
`flutter_test`, and `flutter`.
2. The "universes" `{flutter_tools}` and `{flutter,
flutter_localizations, flutter_goldens}` can use different packages
versions, as they are not resolved together. --> We do not need to
upgrade them in sync, we can first do one "universe", then the other.
Based on these assumptions, we use
https://github.com/mosuem/pubspec_merger.dart to merge all packages in
the `flutter` universe into a top-level pub workspace.
The `flutter` and `flutter_tools` workspaces being separate also ensures
that changes to `flutter` will not inadvertently break `flutter_tools`,
with not-so-nice consequences for our users which would be unable to run
`flutter upgrade`.
There is a third "top-level" pubspec besides `./pubspec.yaml` and
`packages/flutter_tools/pubspec.yaml`, namely
`packages/flutter_tools/.../widget_preview_scaffold/pubspec.yaml`. This
is an artifact due to it living under `flutter_tools`, so it can't be
part of the `./pubspec.yaml` workspace. Moving it would be a larger
change, and out of the scope of this PR.
This required a rewrite of the update-packages tool, but the main
functionality stays the same, as well as the argument names, to ensure a
seamless transition.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
This change removes references to Observatory, including:
- Deprecated flags
- Deprecated embedder APIs
- Outdated documentation
- Documentation instances where "VM service" should have been used
- Incorrectly named tests / directories
As a part of this change, `--serve-observatory` is no longer a valid
flag.
Observatory is still available for now via the `_serveObservatory` RPC,
but will be removed in a follow up PR once we've prepared for breakages
in G3.
Work towards https://github.com/dart-lang/sdk/issues/50233
FYI @a-siva
Switch Flutter to use pub workspaces as a preparation to unpin selected
packages.
Assumptions:
1. No packages in this repository are published to pub.dev --> We can
use `any` dependencies in most local pubspecs, as the global constraint
defines the version. An exception are the packages used outside of this
repo with an `sdk` dependency, namely `flutter_localizations`,
`flutter_test`, and `flutter`.
2. The "universes" `{flutter_tools}` and `{flutter,
flutter_localizations, flutter_goldens}` can use different packages
versions, as they are not resolved together. --> We do not need to
upgrade them in sync, we can first do one "universe", then the other.
Based on these assumptions, we use
https://github.com/mosuem/pubspec_merger.dart to merge all packages in
the `flutter` universe into a top-level pub workspace.
The `flutter` and `flutter_tools` workspaces being separate also ensures
that changes to `flutter` will not inadvertently break `flutter_tools`,
with not-so-nice consequences for our users which would be unable to run
`flutter upgrade`.
There is a third "top-level" pubspec besides `./pubspec.yaml` and
`packages/flutter_tools/pubspec.yaml`, namely
`packages/flutter_tools/.../widget_preview_scaffold/pubspec.yaml`. This
is an artifact due to it living under `flutter_tools`, so it can't be
part of the `./pubspec.yaml` workspace. Moving it would be a larger
change, and out of the scope of this PR.
This required a rewrite of the update-packages tool, but the main
functionality stays the same, as well as the argument names, to ensure a
seamless transition.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
Unfortunately `10_google3_bug.yml` comes before `2_bug.yml`.
This changes the name (slightly) of the issue templates based on the
instructions from GitHub on what to do when you have 10+ issue templates
(as a side-note: I wonder if we need/still use umbrella bugs for the
feature tracker, or two types of performance bugs)
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
Reverts: flutter/flutter#156440
Initiated by: zanderso
Reason for reverting: Failing in post submit with
```
[2024-10-08 18:00:22.743647] [STDOUT] stdout: [!] CocoaPods could not find compatible versions for pod "Google-Mobile-Ads-SDK":
[2024-10-08 18:00:22.743695] [STDOUT] stdout: In Podfile:
[2024-10-08 18:00:22.743718] [STDOUT] stdout: google_mobile_ads (from `.symlinks/plugins/google_mobile_ads/ios`) was resolved t
Original PR Author: flutter-pub-roller-bot
Reviewed By: {fluttergithubbot}
This change reverts the following previous change:
This PR was generated by `flutter update-packages --force-upgrade`.
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
