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

warning from swift demo #166

Closed
dakeshi opened this Issue Oct 11, 2016 · 6 comments

Comments

Projects
None yet
4 participants
@dakeshi
Contributor

dakeshi commented Oct 11, 2016

I download and pod install for swift demo and got the following warning in multiple files:

Conflicting nullability specifier on return types, 'nullable' conflicts with existing specifier 'nonnull'

FIRApp.h:71:1: 
FIREmailPasswordAuthProvider.h:35:1: 
FIRFacebookAuthProvider.h:34:1: 
FIRGoogleAuthProvider.h:36:1: 
FIRAuth.h:97:1: 
FIRAuthCredential.h:27:1: 
FIRUser.h:72:1:
FIRUser.h:263:1: 
FIRAuthUIBaseViewController.h:48:1: 
FIRAuthUI.h:117:1: 

It seems that NS_ASSUME_NONNULL_BEGIN and nullable make a trouble in the header file.

Describe your environment

  • Swift: 3.0
  • iOS version: ios 10.0.2
  • FirebaseUI version: 0.6.1
  • CocoaPods Version: 1.0.1

@dakeshi dakeshi changed the title from warning from swit demo to warning from swift demo Oct 11, 2016

@morganchen12

This comment has been minimized.

Show comment
Hide comment
@morganchen12

morganchen12 Oct 11, 2016

Contributor

Many of these are in upstream Firebase (FIRAuth.h, FIRAuthCredential.h, FIRUser.h, FIRApp.h). Fixing these is as easy as deleting the nullable annotations on the offending methods.

Contributor

morganchen12 commented Oct 11, 2016

Many of these are in upstream Firebase (FIRAuth.h, FIRAuthCredential.h, FIRUser.h, FIRApp.h). Fixing these is as easy as deleting the nullable annotations on the offending methods.

@morganchen12 morganchen12 self-assigned this Oct 11, 2016

@morganchen12 morganchen12 added the bug label Oct 11, 2016

@dakeshi

This comment has been minimized.

Show comment
Hide comment
@dakeshi

dakeshi Oct 12, 2016

Contributor

In the case of FIRAuth, the following method makes a warning:

- (nullable instancetype)init NS_UNAVAILABLE;

I agree that it can be solved with deleting nullable annotations from init method.

Contributor

dakeshi commented Oct 12, 2016

In the case of FIRAuth, the following method makes a warning:

- (nullable instancetype)init NS_UNAVAILABLE;

I agree that it can be solved with deleting nullable annotations from init method.

@morganchen12

This comment has been minimized.

Show comment
Hide comment
@morganchen12

morganchen12 Oct 12, 2016

Contributor

Fixed in 633cebc. There's a Google-internal change to fix the nullability specifiers in upstream Firebase as well.

I'm going to close this issue now since there's no more actions to be taken, but keep in mind you won't see the fix until both Firebase and FirebaseUI make new releases.

Contributor

morganchen12 commented Oct 12, 2016

Fixed in 633cebc. There's a Google-internal change to fix the nullability specifiers in upstream Firebase as well.

I'm going to close this issue now since there's no more actions to be taken, but keep in mind you won't see the fix until both Firebase and FirebaseUI make new releases.

@warby613

This comment has been minimized.

Show comment
Hide comment
@warby613

warby613 Oct 13, 2016

Rather than deleting the nullable annotation, a more passive workaround is to simply suppress the nullability warning for the offending line using #pragma directives:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wnullability"
- (nullable instancetype)init NS_UNAVAILABLE;
#pragma clang diagnostic pop

warby613 commented Oct 13, 2016

Rather than deleting the nullable annotation, a more passive workaround is to simply suppress the nullability warning for the offending line using #pragma directives:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wnullability"
- (nullable instancetype)init NS_UNAVAILABLE;
#pragma clang diagnostic pop
@6ewis

This comment has been minimized.

Show comment
Hide comment
@6ewis

6ewis Nov 30, 2016

@morganchen12 Instead of waiting for the new releases - is that appropriate to change those lines to "(instancetype)init NS_UNAVAILABLE;" as per your fix 633cebc

6ewis commented Nov 30, 2016

@morganchen12 Instead of waiting for the new releases - is that appropriate to change those lines to "(instancetype)init NS_UNAVAILABLE;" as per your fix 633cebc

@morganchen12

This comment has been minimized.

Show comment
Hide comment
@morganchen12

morganchen12 Nov 30, 2016

Contributor

@6ewis the new releases have been out for some time now; if you're still seeing these warnings try running pod update and clearing out DerivedData/CocoaPods cache.

If this still doesn't work for you, removing the errant nullables in the headers should work as well, though you'll have to do so every time you run pod install.

Contributor

morganchen12 commented Nov 30, 2016

@6ewis the new releases have been out for some time now; if you're still seeing these warnings try running pod update and clearing out DerivedData/CocoaPods cache.

If this still doesn't work for you, removing the errant nullables in the headers should work as well, though you'll have to do so every time you run pod install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment