Do not pass inhibit warnings compiler flags for Swift source files.

[dnkoutso]

closes #9013

It will probably be for 1.7.5 release and will add a milestone.

Passing those flags in Xcode 11 Beta 4 fails to compile.

[dnkoutso]

We also pass -suppress-warnings for Swift https://github.com/CocoaPods/CocoaPods/blob/1-7-stable/lib/cocoapods/target/build_settings.rb#L785 so no need to use SWIFT_SUPPRESS_WARNINGS

[segiddins]

Should file a radar for this regression

[dnkoutso]

Will do but I do not expect that to be fixed anytime soon. Maybe that is my answer not to point to 1-7-stable and have it on master for 1.8.x.

[dnkoutso]

https://openradar.appspot.com/radar?id=4947476331102208

[mrgrauel]

A fast release - 1.7.5 - would be awesome 👍

[dnkoutso]

We are waiting a day or two to hear from Apple if this change was intended or a regression from their part.

If people are blocked please use https://bundler.io/ and point to this branch or commit to be unblocked.

We do not want to release a 1.7.5 and then release 1.7.6 again if this is a regression from Apple.

[lilyball]

This doesn't seem like an Xcode regression. It seems like an Xcode bugfix. I just compiled my project using Xcode 10.2.1 and checked, and it did not pass the per-file compiler flags to swift files. In Xcode 11 beta 4 it's now passing the per-file compiler flags to swift files.

The fact is, these flags never worked on Swift. We just didn't notice before because Xcode wasn't passing them along. Now that it is passing them along, it's obvious that the flags shouldn't be applied to swift files.

I strongly recommend publishing a 1.7.5 for this instead of waiting.

[dnkoutso]

Shipped with 1.7.5.

[Coeur]

We do not want to release a 1.7.5 and then release 1.7.6 again

@dnkoutso
Well, see #9013 (comment)

[barrypress]

@Coeur is right about #9013. The attached project is a clean iOS project, then including the Down pod, and fails to compile. I believe the problem is that the PR did not address the flag no-shorten-64-to-32

DownTest.zip

[dnkoutso]

This happens because the podspec specifies compiler_flags https://github.com/iwasrobbed/Down/blob/master/Down.podspec#L20

We will have to re-think this through as a relatively bigger change to handle compiler flags for different source file types.

[lilyball]

In the short term we should probably just stop passing per-file compilation flags to Swift files. It apparently never worked before, so omitting them entirely restores the old behavior. Then we can explore adding a separate option for Swift compilation flags.

[amorde]

That's not true, there are per-file complication flags for Swift that do work, the problem was CocoaPods was including Objective-C-specific flags when it shouldn't have been.

There's the -Xcc option for passing flags down to the Objective-C/C/C++ compiler, maybe we should be using that instead?

[lilyball]

swiftc has some flags that make sense to pass (though I'm not sure which ones are appropriate as per-file flags), but it's clear that Xcode prior to Xcode 11 Beta 4 wasn't passing the per-file flags to swiftc. This is really easy to test; just create a new project in Xcode 10, add a dummy per-file compilation flag to a Swift file, and build. Not only does the build succeed despite the garbage flag, but if you inspect the build log, the flag was never passed.

But more than that, given that compilation flags are unique to each compiler, it simply doesn't make sense for CocoaPods to have a single property that it applies to all source files. It should have a property for clang flags, and a property for swiftc flags. I'm also not sure why it's even using per-file compilation flags at all instead of just passing these in the appropriate per-language build setting.

[amorde]

Yes that's the issue, the compiler_flags DSL was introduced before Swift was released and it was never updated. We might add a swift_compiler_flags to match but no concrete plans for that yet

[barrypress]

Perhaps I’m being naive, and in any event I owe you a big thanks for being so responsive. That said, I didn’t see a plan for what the fix will be, nor for when users might expect it. Is it unreasonable to ask that?

…

On Jul 24, 2019, at 2:30 PM, Eric Amorde ***@***.***> wrote: Yes that's the issue, the compiler_flags DSL was introduced before Swift was released and it was never updated. We might add a swift_compiler_flags to match but no concrete plans for that yet — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9014?email_source=notifications&email_token=AABILZKMM5NGKBF3CSJDCQDQBDCY3A5CNFSM4IEVW2ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2XVO2A#issuecomment-514807656>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABILZIQCXVCQDKJINNHGGTQBDCY3ANCNFSM4IEVW2ZA>.

[Coeur]

@barrypress :
All things related to the issue are written here between your two messages.
Feel free to do a Pull Request adopting either amorde idea (add a swift_compiler_flags) or lilyball idea (stop passing per-file compilation flags to Swift files) if you need a fix urgently. Otherwise, tell your userbase to avoid Xcode 11 beta 4+ for a few weeks?

[lilyball]

@barrypress You can also submit a PR to Down that removes that flag from the podspec as per this comment. As the comment says, this will likely introduce some warnings in the C code, but you can then handle that by adding the appropriate #pragmas around the code in question to disable the warning in a targeted fashion.

[Coeur]

@barrypress as there wasn't much visible move on that in the past two weeks, I would suggest that you open a specific GitHub issue in order to track that Xcode 11 issue with pods requiring compiler_flags that are incompatible with Swift. Then link that issue to this pull request for reference.