Skip to content
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

Closed
sendoa opened this issue Oct 22, 2015 · 20 comments
Closed

inhibit_all_warnings! doesn't inhibit all warnings ;-) #4423

sendoa opened this issue Oct 22, 2015 · 20 comments

Comments

@sendoa
Copy link

@sendoa sendoa commented Oct 22, 2015

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:

Unnecessary check for 'iOSApplicationExtension'; minimum deployment target ensures guard will always be true

My current Podfile:

platform :ios, '9.0'
# Uncomment this line if you're using Swift
use_frameworks!
inhibit_all_warnings!

target 'My Project' do
    pod 'Alamofire', '~> 3.0'
    pod 'ObjectMapper', '~> 0.19'
    pod 'SWRevealViewController', '~> 2.3'
    pod 'XCDYouTubeKit', '~> 2.3'
    pod 'JTSImageViewController', '~> 1.5'
end

I am using

  • OS X El Capitan (10.11.0)
  • Xcode Version 7.0
  • Swift 2

Thank you for all the great work!

@segiddins
Copy link
Member

@segiddins segiddins commented Oct 22, 2015

I think this warning in particular will be fixed by an open PR to use the pods actual deployment target.

@cnoon
Copy link

@cnoon cnoon commented Oct 25, 2015

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

@segiddins
Copy link
Member

@segiddins segiddins commented Oct 25, 2015

@cnoon can you verify the relevant cocoapods PR fixes the issue for you?

@cnoon
Copy link

@cnoon cnoon commented Oct 26, 2015

I've never setup a CocoaPods dev build before. Followed this guide and I'm stuck in weird bundle install issues. Maybe someone else could try this out that already has it set up?

@frogcjn
Copy link

@frogcjn frogcjn commented Nov 14, 2015

same issue here

platform :ios, '8.0'
use_frameworks!
inhibit_all_warnings!

pod 'IQKeyboardManagerSwift' , '>= 3.3.4'
@segiddins
Copy link
Member

@segiddins segiddins commented Nov 16, 2015

This should now be fixed on master.

@segiddins segiddins closed this Nov 16, 2015
@aaronwhite
Copy link

@aaronwhite aaronwhite commented Jan 19, 2016

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

platform :ios, '9.0'
xcodeproj 'myproj'
use_frameworks!
inhibit_all_warnings!

pod 'ReactiveCocoa', '~> 4.0.0-RC1'
pod 'Alamofire',     '~> 3.0'

@adomanico
Copy link

@adomanico adomanico commented Jan 22, 2016

Yes seeing this as well for the following pods:

pod 'Masonry'
pod 'ChimpKit'
pod 'Appirator'

this seems to be an issue with use_frameworks!

@orta
Copy link
Member

@orta orta commented Jan 22, 2016

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 )

@adomanico
Copy link

@adomanico adomanico commented Jan 22, 2016

"C99 forbids casting non-scalar type...." and iOS 9 deprecation warnings are the ones that I am seeing

@kurko
Copy link

@kurko kurko commented Feb 6, 2016

As of 0.39.0, I'm getting

** BUILD SUCCEEDED **

 -> UDSync (0.1.0)
    - WARN  | xcodebuild:  Alamofire/Source/Request.swift:208:20: warning: unnecessary check for 'OSX'; minimum deployment target ensures guard will always be true
    - WARN  | xcodebuild:  Alamofire/Source/ParameterEncoding.swift:230:12: warning: unnecessary check for 'OSX'; minimum deployment target ensures guard will always be true
    - WARN  | xcodebuild:  Alamofire/Source/MultipartFormData.swift:259:12: warning: unnecessary check for 'OSX'; minimum deployment target ensures guard will always be true

Analyzed 1 podspec.

[!] The spec did not pass validation, due to 3 warnings (but you can use `--allow-warnings` to ignore them).

UPDATE

Fixed in beta.

@virl
Copy link

@virl virl commented May 31, 2016

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.

@RishabhTayal
Copy link

@RishabhTayal RishabhTayal commented Jul 18, 2017

I found this workaround. Put the below script in your Podfile and do pod install.

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['GCC_WARN_INHIBIT_ALL_WARNINGS'] = "YES"
        end
    end
end
@sareninden
Copy link

@sareninden sareninden commented Nov 28, 2017

You can also suppress the warnings per included pod (which does work....)

pod 'Alamofire', :inhibit_warnings => true

@bj97301
Copy link

@bj97301 bj97301 commented Mar 3, 2018

I had to clean my project to get the warnings to go away.

@bolee
Copy link

@bolee bolee commented Oct 9, 2018

@sareninden and @RishabhTayal not working in my Xcode 9.4.1 with Objective-C.

@bolee
Copy link

@bolee bolee commented Oct 9, 2018

I had to clean my project to get the warnings to go away.

use which ways?

@zackdotcomputer
Copy link

@zackdotcomputer zackdotcomputer commented Mar 1, 2020

Still struggling with this one, these days with

pod 'AWSMobileClient', '~> 2.12.0', :inhibit_warnings => true

in a Swift project.

Even with the above inhibit, an inhibit_all_warnings! at the top of the file, and this block at the bottom:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['SWIFT_SUPPRESS_WARNINGS'] = 'YES'
        end
    end
end

I'm still getting "Pointer is missing a nullability type specifier" warnings after running pod install and a local clean.

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 -Xcc -Wno-nullability-completeness to the Swift flags for my final target. So I'm guessing this is coming from my target and not from the Cocoapods, so there's no way to suppress the warning on Pods's side of the build?)

@tylerjames
Copy link

@tylerjames tylerjames commented Mar 2, 2020

@zackdotcomputer
I'm getting this as well while using AWS libraries. Went from 8 to a cool 137 warnings.

Where exactly do you put -Xcc -Wno-nullability-completeness?

@zackdotcomputer
Copy link

@zackdotcomputer zackdotcomputer commented Mar 2, 2020

@tylerjames

  1. Select my app project in the navigator
  2. Select my app's target in the main window
  3. Select "Build Settings" and make sure it's filtered to "All" rather than "Basic" or "Customized".
  4. Search for "Swift" and find the "Other Swift Flags" setting under the "Swift Compiler - Custom Flags" section.
  5. Double click and add it to the bottom of the list there.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.