-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
changes to prefer_final_locals
breaking flutter analyze trybot
#1342
Comments
I think that whatever value is provided by |
I glanced at a few of these: I don't see any that are false positives. |
Thanks! I guess the question now becomes whether these new semantics line up with what Flutter wants from the rule. @Hixie, curious how you feel. With Sam's fix, the follow code now lints: for (var i in [1, 2, 3]) { // LINT
print(i);
} and should read: for (final i in [1, 2, 3]) { // OK
print(i);
} If you're OK with that change, we can put together a PR to fix up the Flutter codebase. |
I think the more egregious / non-muscle-memory changes are when an explicit type is provided, like: for (final _BenchmarkResult result in _results) {
results[result.name] = result.value;
} |
Yeah, as much as I like |
I agree with this. As a general rule I think mutability is the degenerate case and not the other way around. That said, we do have a decision to make here. I think our choices are probably down to:
If we opt for 3, it may make sense to add a new rule (sigh) for this case specifically (something like /cc @bwilkerson FYI |
I definitely would go for 3b (have separate lints for variable declarations, parameters, for loop variables, etc). |
https://ci.chromium.org/p/dart/builders/luci.dart.ci.sandbox/flutter-analyze/107
841 issues like this:
Addressing these warnings blocks integration of
0.1.77
. A few options:Regardless of what we decide we should probably start w/
/cc @srawlins
The text was updated successfully, but these errors were encountered: