-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[google_sign_in] Migrate to nnbd #3329
Changes from all commits
cca5e58
df46cab
9b52a79
f0065a0
105a6df
91ff05c
c76338c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,7 +2,7 @@ name: google_sign_in | |
description: Flutter plugin for Google Sign-In, a secure authentication system | ||
for signing in with a Google account on Android and iOS. | ||
homepage: https://github.com/flutter/plugins/tree/master/packages/google_sign_in/google_sign_in | ||
version: 4.5.9 | ||
version: 5.0.0-nullsafety | ||
|
||
flutter: | ||
plugin: | ||
|
@@ -16,27 +16,21 @@ flutter: | |
default_package: google_sign_in_web | ||
|
||
dependencies: | ||
google_sign_in_platform_interface: ^1.1.1 | ||
google_sign_in_platform_interface: ^2.0.0-nullsafety | ||
flutter: | ||
sdk: flutter | ||
meta: ^1.0.4 | ||
# The design on https://flutter.dev/go/federated-plugins was to leave | ||
# this constraint as "any". We cannot do it right now as it fails pub publish | ||
# validation, so we set a ^ constraint. | ||
# TODO(amirh): Revisit this (either update this part in the design or the pub tool). | ||
# https://github.com/flutter/flutter/issues/46264 | ||
google_sign_in_web: ^0.9.1 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This pubspec is declaring a 'default_package: google_sign_in_web' for the 'web' platform (line 16), however it's removing the dependency on the web package here. I don't think this'll work for web users. This should be documented in the CHANGELOG.md entry. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We had discussed this somewhere in this PR and decided to remove the default package. I am not familiar with how that needs to be executed upstream. Could you please help with that David? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not really sure if this is used on-demand or validated somehow; I think the web endorsement should be removed (otherwise we're cheating pub.dev into reporting "web" support for the null-safe version, which is not true) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tracking here: flutter/flutter#72239 |
||
meta: ^1.3.0-nullsafety.6 | ||
|
||
dev_dependencies: | ||
http: ^0.12.0 | ||
flutter_driver: | ||
sdk: flutter | ||
flutter_test: | ||
sdk: flutter | ||
pedantic: ^1.8.0 | ||
pedantic: ^1.10.0-nullsafety.1 | ||
integration_test: | ||
path: ../../integration_test | ||
|
||
environment: | ||
sdk: ">=2.1.0 <3.0.0" | ||
flutter: ">=1.12.13+hotfix.4" | ||
sdk: ">=2.12.0-0 <3.0.0" | ||
flutter: ">=1.12.13+hotfix.5" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the analyzer able to detect the
_lastMethodCall == null
check earlier?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit annoyed by this as well but I have seen it in many other places. My interpretation is that flow analysis only catches variables that are local to current scope. For instance:
is fine. However:
is not. You need the bang operator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks. I learned something new. I wonder if @munificent has any thoughts about whether this is the intended design or a temporary limitation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an intended design but a known pain point that we'd like to improve if we can figure out how. The problem is that promoting fields isn't sound. In many cases, the compiler can't prove that there is not a class elsewhere that implements that class's interface and overrides with the field with a getter. Or there could be some re-entrant method call on the instance that changes the field's value between when it is checked for null and when it is later used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah. that makes sense. The re-rentrant method call is interesting. Could that occur even if the method that is checking for
null
isn't async?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. "Re-entrant" is maybe not the best word, but just consider any case between checking a field for null and accessing it where you could end up running other code on the same instance. This is contrived, but should give you the idea: