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
inhibit_all_warnings! doesn't inhibit all warnings ;-) #4423
Comments
I think this warning in particular will be fixed by an open PR to use the pods actual deployment target. |
I agree @segiddins. I just created a sample project to demonstrate the issue we face on Alamofire. Since we're supporting four different variations of the framework for each OS (iOS, OSX, tvOS and watchOS), we have a significant amount of availability checks to handle the different cases. I was originally going to file a radar, but I think what Apple is doing already is the correct approach. I have many more details in the README of the sample project, but the only solution that I could come up with was to build each pod against the deployment target specified in the podspec for that Pod. That's the only way we (the Pod developers) can ensure availability warnings won't be triggered. More details can be found in Alamofire #871. cc @kylef for visibility |
@cnoon can you verify the relevant cocoapods PR fixes the issue for you? |
I've never setup a CocoaPods dev build before. Followed this guide and I'm stuck in weird |
same issue here
|
This should now be fixed on master. |
This doesn't appear to be 'closed' as of 0.39. The following Podfile still generates 1 warning each from the two pods included despite the inhibit flag
|
Yes seeing this as well for the following pods:
this seems to be an issue with use_frameworks! |
What are the warnings? I'm not sure it's possible for CP to cover all the warnings anymore ( I'm pretty sure we apply a llvm flag that says "no warnings" with this and this flag now doesn't cover all warnings ) |
"C99 forbids casting non-scalar type...." and iOS 9 deprecation warnings are the ones that I am seeing |
As of 0.39.0, I'm getting
UPDATE Fixed in beta. |
Error still persists when Swift project uses some Objective-C code: pods warnings (deprecated UIAlertView) are not inhibited for Objective-C code, because that code uses auto-generated *-Swift.h headers (which contain references to UIAlertView). Example pod: Armchair. |
I found this workaround. Put the below script in your
|
You can also suppress the warnings per included pod (which does work....) pod 'Alamofire', :inhibit_warnings => true |
I had to clean my project to get the warnings to go away. |
@sareninden and @RishabhTayal not working in my Xcode 9.4.1 with Objective-C. |
use which ways? |
Still struggling with this one, these days with
in a Swift project. Even with the above inhibit, an
I'm still getting "Pointer is missing a nullability type specifier" warnings after running Am I missing an obvious issue with my approach here or is this just a new case not covered by the existing warning-inhibit macros? (Edit: investigating further, it looks like the nullability warning is generated AFTER the pod framework is built and linked to my final target. The only way I've found to suppress them is to add |
@zackdotcomputer Where exactly do you put |
|
I'm working on a project (Swift) with a deployment target of 9.0 and using the Alamofire pod. I get the following warning even though I have
inhibit_all_warnings!
flag enabled in my Podfile:My current Podfile:
I am using
Thank you for all the great work!
The text was updated successfully, but these errors were encountered: