LGTM but we will land this in a few weeks at a specific time so that we limit disruptions to the tree and don't make cherry picks to/from an upcoming stable release more complicated.

Could you post exactly what you ran to auto-generate this so we can reproduce this PR (we won't be able to land this exact one for the reasons above)

If there are any ahead of time changes we can make to make this smoother (like the LinkedHashMap changes), I'd be happy to see those land first.

This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Thanks for the input, @matanlurey!

Could you post exactly what you ran to auto-generate this

Sure, when analysis_options.yaml has been adjusted to disable always_specify_types and enable type_annotate_public_apis, specify_nonobvious_local_variable_types, and omit_obvious_local_variable_types, and the LinkedHashMap constructor invocation issues have been addressed, it goes as follows:

> dart fix --apply --code=omit_obvious_local_variable_types
> bin/cache/dart-sdk/bin/dart --enable-asserts /usr/local/google/home/eernst/devel/dart/flutter/justin_flutter/flutter/dev/tools/bin/format.dart

Note that the dart fix step gives rise to approximately 54 analyzer crashes (see dart-lang/sdk#60856 for details). I suspect that this could cause some libraries to be processed partially or not at all during the dart fix step. Surely it would be nice to fix that before the final PR on this topic is created.

Next, I haven't yet resolved how to update the snippet code. The following command reports a number of testing failures after these steps:

> bin/cache/dart-sdk/bin/dart --enable-asserts /usr/local/google/home/eernst/devel/dart/flutter/justin_flutter/flutter/dev/bots/analyze_snippet_code.dart --verbose

It might also be possible (and it may or may not be appropriate) to disable omit_obvious_local_variable_types for snippets.

so we can reproduce this PR (we won't be able to land this exact one for the reasons above)

Right, I did expect that it would have to be handled like that.

If there are any ahead of time changes we can make to make this smoother (like the LinkedHashMap changes), I'd be happy to see those land first.

Yes, presumably the best way to change those three locations would be to use the type Map and a map literal rather than invoking the LinkedHashMap constructor. This would require at least some other locations to change, too, because they expect the type to be LinkedHashMap. The point is that, as far as I know, no actual benefit is achieved by insisting that it must be precisely a LinkedHashMap, so we might just as well follow the normal rules also in these 3 locations.

Next, we could change analysis_options.yaml: Disable always_specify_types and enable type_annotate_public_apis and specify_nonobvious_local_variable_types. These changes should not give rise to any new lint messages, they will just allow local variable declarations to omit the type when it is obvious, and also allow everything else which was allowed before.

Later, when we perform the actual changes where local variable type annotations are removed, we just use the freedom to do this. This can be done in one big step or in any number of smaller steps.

If it is done in multiple steps then each of them would involve temporarily changing analysis_options.yaml to enable omit_obvious_local_variable_types in order to get the fixes, and then disabling it again.

Finally, as part of the big step or the last small step, omit_obvious_local_variable_types is enabled (as part of the PR rather than temporarily).

I like the incremental approach idea, if it's not too much overhead. The current PR is so large it's hard to view in GitHub, so it's a bit of a leap of faith unless we really trust the analyzer.

I think the resulting change will be just as large, and the incrementalism is mostly for the benefit of getting smaller changes out of the way so less manual fixes are required. I do trust the analyzer in this case.

Greetings from stale PR triage! 👋
Should we close this preview for now? I do have plans to follow up on actually landing this.

Should we close this preview for now? I do have plans to follow up on actually landing this.

OK, sounds good!

It was already planned (see this comment) that the actual changes should be handled in some other PR(s) and this one should only be used to document the proposed changes.