Remove unsafe implicit cast warnings in Flutter code base

[kasperl]

The Flutter analysis options currently contain:

strong_mode_down_cast_composite: ignore

Enabling those warnings leads to >100 warnings in the Flutter code base like these:

[warning] Unsafe implicit cast from 'Map<dynamic, dynamic>' to 'Map<String, dynamic>'. 
[warning] Unsafe implicit cast from '(ByTooltipMessage) → Finder' to '(SerializableFinder) → Finder'.
...

I suspect that a lot of these will require changes to the Flutter code base, but we should make sure that the type system isn't making this unnecessarily hard.

Reproduction steps:

   $ git clone https://github.com/flutter/flutter.git
   $ cd flutter
   $ bin/flutter update-packages
   <<comment out the strong_mode_down_cast_composite in .analysis_options_repo>>
   $ bin/flutter analyze --flutter-repo

[kasperl]

If these warnings are only needed because we don't do the correct runtime strong mode checks, we should think about what state we want this to be in for 1.23.

[kasperl]

We believe we can get rid of this warning and turn it into a lint that users can enable if they want help finding areas where runtime checks might fail for them.

[kasperl]

We have reached the decision to turn off the strong_mode_down_cast_composite warning by default, but we will do it in a few steps. First, we will turn it off by default in Flutter projects but keep it on for web projects.

It looks like analysis options are dealt with in a lot of places in the analyzer code base, @pq? It feels hard to manipulate the options map and add the ignore there, so here's a suggestion on how to turn this off for Flutter projects by passing down the hasFlutterDependency flag to the strong mode checker: https://codereview.chromium.org/2703253006/.

Do you have cycles to look at this, Phil, and figure out what the best path forward is?

[pq]

Do you have cycles to look at this, Phil, and figure out what the best path forward is?

👍 Happy to take a look.

[kasperl]

Turned the warning into a hint in fa2a3a1, but had to revert it.

[kasperl]

Finally landed turning this into a lint in 2fe8485.

[mit-mit]

@kasperl are you still working on this?

[kasperl]

@mit-mit The work is done, but it hasn't been rolled into Flutter yet. We could turn this into a Flutter issue blocked on rolling the Dart SDK dependency past the next dev channel release -- and close this one. That's probably the best approach.

[kasperl]

@mit-mit This change will be in 1.23.0-dev.6.0. Will go ahead and close this issue.

[kasperl]

Filed flutter/flutter#8783. Closing this one.

[leafpetersen]

What was the final resolution of this? I don't see it surfacing as a hint. Is it now an opt in lint? If so, what are the instructions for enabling it?

[pq]

I believe it's now only shown if you have strong warnings enabled. I'm not sure how that gets done though! (Not seeing an option in dartanalyzer...)

cc @bwilkerson who may know

[leafpetersen]

If by strong warnings, you mean AnalysisOptionsImpl.strongModeHints, I think that's only available programmatically, and is really more of a testing feature for us at this point.

[pq]

I think that's right -- and was under the impression that was the desired approach... I'll leave it to @kasperl to clarify though!

[leafpetersen]

Ok. For context, I'm writing the changelog, and I want to know what to say about this. That is, should I be saying "this is gone" or "this is now opt in via path XXX", or...

[kasperl]

You can opt in through an analysis options file - explicitly requesting to turn the specific hint into a warning or an error.

…

On Tue, Mar 28, 2017, 22:45 Leaf Petersen ***@***.***> wrote: Ok. For context, I'm writing the changelog, and I want to know what to say about this. That is, should I be saying "this is gone" or "this is now opt in via path XXX", or... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28588 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACDmpq8UC-IJjR-a4DdiOmCKi5CP4op3ks5rqXFYgaJpZM4LzjG7> .

[leafpetersen]

Can you elaborate more? I've not been able to surface this in any way, even as a hint. Adding

  errors:
    down_cast_composite: error

to an analysis options file still doesn't surface it in any way that I can see.

[kasperl]

Ack, @leafpetersen. I've messed this up. The strong mode checker filters out hints aggressively without consulting the analysis options.

Fix here: https://codereview.chromium.org/2784473004/

[DanTup]

We have reached the decision to turn off the strong_mode_down_cast_composite warning by default

Is there any more info on the reasons for this decision? To me it seems really strange that "opting in to strong mode" would not give you protection against this by default.

A colleague asked me today why his analysis_options.yaml file wasn't working and it turned out to be that he didn't know about this option and had concluded that strong mode was broken or "not strong". From the outside, based on only the info in this case it seems like the default was changed based on it being easy for some existing code rather than doing what's best for Dart code going forwards. I don't understand why the Flutter code can't be a) changed b) have explicit casts added or c) continue to opt-out if they really want (IMO a/b are best since the decision about whether it's valid can be made on a case-by-case basis).