Conversation
|
|
||
| /// Builds the current project for this device, with the given options. | ||
| Future<void> buildForDevice( | ||
| ApplicationPackage package, { |
There was a problem hiding this comment.
package wasn't used in any of the subclass implementation, remove.
| @override | ||
| Future<bool> stopApp( | ||
| ApplicationPackage app, { | ||
| ApplicationPackage? app, { |
There was a problem hiding this comment.
This is where the nullability mismatch caused the runtime test failure seen during the roll
Since covariant has been removed from the base class signature, there was correctly an error when this wasn't nullable.
| ); | ||
| } | ||
|
|
||
| if (package == null) { |
There was a problem hiding this comment.
Rearranged this check to be above the 'Launching ${package!.displayName} ' call, which would crash.
| @override | ||
| Future<bool> isAppInstalled( | ||
| AndroidApk app, { | ||
| ApplicationPackage app, { |
There was a problem hiding this comment.
so for this call, will we just be more permissive and allow any ApplicationPackage?
There was a problem hiding this comment.
I wonder if the right solution to this is not to make Device:
abstract class Device<A extends ApplicationPackage> {
isAppInstalled(A app, ...) {}
}There was a problem hiding this comment.
That would be a much better solution, but it also means every single usage of the base class Device becomes Device<ApplicationPackage> if we can't derive the implemented type, and we have hundreds of them.
info: Specify type annotations. (always_specify_types)
I gave up with about 400 more warnings to go:
e780f1d
There was a problem hiding this comment.
What do you want me to do with this PR?
There was a problem hiding this comment.
let me make one more pass, we can land as is
| @override | ||
| Future<bool> uninstallApp( | ||
| AndroidApk app, { | ||
| ApplicationPackage app, { |
There was a problem hiding this comment.
why not covariant AndroidApk here?
There was a problem hiding this comment.
Because covariant AndroidApk would turns off the static analysis for this type, so if the base class switched to ApplicationPackage? say, the analyzer wouldn't complain and we'd be back where we started.
| @override | ||
| Future<LaunchResult> startApp( | ||
| AndroidApk package, { | ||
| AndroidApk? package, { |
There was a problem hiding this comment.
Why allow null for Android app?
There was a problem hiding this comment.
It should be nullable because the base class is nullable due to web. That's the bug this is fixing--covariant was hiding that null could be passed in, which in some cases caused crashes.
There was a problem hiding this comment.
yup, that was a brain fart on my part
| @override | ||
| Future<bool> stopApp( | ||
| AndroidApk? app, { | ||
| ApplicationPackage? app, { |
There was a problem hiding this comment.
why not covariant AndroidApk?
|
Despite the passing |
|
Going to reopen this and hopefully get new google testing failures. |
Remove
covariantwhere possible to avoid subtle null safety issue. Where it's still useful, remove from base class and pushcovariantinto overrides to by-default enforce nullability wherecovariantisn't needed.See https://dart.dev/guides/language/sound-problems#the-covariant-keyword about how this suppresses the analyzer.
This will need a g3fix.
Note I left the
covariantinstartApp. That one is really a mess since most subclasses do expect it to be non-null, but it is legitimately called as null in the web case. I guess we can leave that one for now until it causes issues...flutter/packages/flutter_tools/lib/src/isolated/resident_web_runner.dart
Lines 242 to 245 in 156c313
Fixes #114090
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.