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)
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
The SkiaGoldHttpOverrides don't have any effect since we never build our own HttpClient, it's always passed in.
This is part 18 of a broken down version of the #140101 refactor.
This particular change is more risky than other changes in this series. While by inspection and some instrumentation testing I'm reasonably sure that my assumptions here are correct, it would behoove us to make sure Skia Gold testing still works post-commit after this lands. To this end, I've included a change to the "inconsequential" test. It should fail the tests. I recommend we land this _with this failure_ to make sure it also fails post-commit, then immediately flag the image as passing and rerun the relevant shard.
We have fiddled with this a bunch, and there is definitively no way to reliably include this, so I am removing it.
Since CI does not cover all possible values, we can't consistently look up images for local testing. We thought removing it from the look up would work fine, and it did for most tests, but there were still some that could not find an image without it.
A brief history on the abi key
- added in https://github.com/flutter/flutter/pull/143621
- disabled in https://github.com/flutter/flutter/pull/148023
- added back in https://github.com/flutter/flutter/pull/148072
- we thought there was only an issue with alphabetizing keys
- removed from local image look up in https://github.com/flutter/flutter/pull/149696
I updated the docs page to also discuss what makes a good key and what does not based on what we learned here.
Fixes https://github.com/flutter/flutter/issues/149435
CI does not comprehensively cover all of the possible abi keys, so some folks can't test locally if their machine's abi does not match CI. This just removes it from the local testing look up. The right image will be summoned, and in CI we can still keep track of it.
Manual recreation of https://github.com/flutter/flutter/pull/148911
Entire PR is just the output of
```
flutter update-packages --force-upgrade
```
followed by (run from the root of the flutter repo)
```
find . -type d -name 'android' | dart dev/tools/bin/generate_gradle_lockfiles.dart --no-gradle-generation --no-exclusion
```
This is part 17 of a broken down version of the #140101 refactor (though this particular dependency didn't actually exist back then).
This only makes one dependency explicit. Further PRs will do the same for other dependencies, until these APIs have no hidden dependencies.
I also snuck in a minor stylistic change, using interpolation instead of explicit `toString`, to make the code more idiomatic. (I'm actually surprised that that didn't trigger a lint, I thought we had a lint to catch that. I must be thinking of something else though.)
This PR makes no effort to keep the order of parameters reasonable. There is an existing TODO to do a refactor sweep later that does nothing but reorder arguments/parameters/fields to be consistent.
This is part 16 of a broken down version of the #140101 refactor.
This only makes one dependency explicit. Further PRs will do the same for other dependencies, until these APIs have no hidden dependencies.
This PR makes no effort to keep the order of parameters reasonable. There is an existing TODO to do a refactor sweep later that does nothing but reorder arguments/parameters/fields to be consistent.
This is part 15 of a broken down version of the #140101 refactor.
This only makes one dependency explicit. Further PRs will do the same for other dependencies, until these APIs have no hidden dependencies.
This PR makes no effort to keep the order of parameters reasonable. There is an existing TODO to do a refactor sweep later that does nothing but reorder arguments/parameters/fields to be consistent.
This is part 14 of a broken down version of the #140101 refactor.
This is an extension of part 8 (#146008), which had omitted removing the filesystem dependency in the SkiaGoldClient class.
This only makes one dependency explicit. Further PRs will do the same for other dependencies, until these APIs have no hidden dependencies.
This particular change attempts to be minimal. I made no effort to keep the order of parameters reasonable here. I have a TODO to do a refactor sweep later that does nothing but reorder arguments/parameters/fields to be consistent.
This is part 13 of a broken down version of the #140101 refactor.
This only makes one dependency explicit. Further PRs will do the same
for other dependencies, until these APIs have no hidden dependencies.
DDS was temporarily pinned to 4.1.0 because 4.2.0 triggered some test
failures (see https://github.com/flutter/flutter/pull/147250). Those
failures should be fixed by vm_service 14.2.2, so this unpins DDS and
rolls both of these packages (along with devtools_shared, which is a DDS
dependency).
(If the bot updates vm_service before this is done, I can rebase over
that will reduce the size of this PR to just a few files)
This is part 12 of a broken down version of the #140101 refactor.
This only makes one dependency explicit. Further PRs will do the same for other dependencies, until these APIs have no hidden dependencies.
Here's another PR with a couple of typos fixed. As you can see there was a typo in _fileReferenceI**n**dentifiers_, in class _ParsedProjectInfo._ Maybe we should do some check on that since I'm not sure if that property is used somewhere outside Flutter?
This is part 11 of a broken down version of the #140101 refactor.
These tests are redundant with the more comprehensive tests now in comparator_selection_test.dart.
This is part 8 of a broken down version of the #140101 refactor.
This only makes one dependency explicit. Further PRs will do the same for other dependencies, until these APIs have no hidden dependencies.
This particular change attempts to be minimal. A future change will apply some formatting cleanup (newlines, reordering parameters and arguments) for clarity.
