Airship iOS SDK 16.11.3 Does Not Compile With Xcode 15b1

[macbellingrath]

Preliminary Info

What Airship dependencies are you using?

SDK v16.11.3, via CocoaPods. Using Core and Automation.

What are the versions of any relevant development tools you are using?

Xcode 15 beta 1 (15A5160n)

Report

What unexpected behavior are you seeing?

Failed compilation of the Airship iOS SDK.

What is the expected behavior?

Successful compilation of the Airship iOS SDK.

What are the steps to reproduce the unexpected behavior?

• Use pod 'Airship', '16.11.3', :subspecs => ['Core', 'Automation'],
• Compile with Xcode 15b1

Do you have logging for the issue?

The underlying issue may be beta toolchain related but I wanted to create this issue to track its resolution.

Stored value type does not match pointer operand type!
  store i64 %98, %TSiSg* %9, align 8, !dbg !746
 i64Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.

Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x000000010a11f91c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  swift-frontend           0x000000010a11eae0 llvm::sys::RunSignalHandlers() + 112
2  swift-frontend           0x000000010a11ff1c SignalHandler(int) + 352
3  libsystem_platform.dylib 0x000000019e8caa24 _sigtramp + 56
4  libsystem_pthread.dylib  0x000000019e89bc28 pthread_kill + 288
5  libsystem_c.dylib        0x000000019e7a9ae8 abort + 180

[rlepinski]

Thanks for the report, trying to figure out how to track down whats failing. If I change my optimization level it works for me. Might be related to https://github.com/apple/swift/issues/66359

[rjohnstoneBBC]

Changing optimization level doesn't seem to work when brought in via SwiftPM

[rlepinski]

If you are ok updating to SDK 17, we now have prebuilt swift packages that use prebuilt frameworks - https://github.com/urbanairship/ios-library-prebuilt, that should workaround the issue for now.

I am really hoping beta 2 fixes this issue, if not I guess ill have to audit 300ish files looking for usages of the same variable name in different scopes.

[zmknox]

Tried compiling an app w/ this library (added w/ CocoaPods) in beta 2 and getting the same errors. Changing optimization settings didn't seem to do anything

[rlepinski]

@zmknox downloading beta 2 now to see how to workaround this. Did you change the optimization level on the airship pod target?

[zmknox]

Did you change the optimization level on the airship pod target?

Yes (at least for the debug scheme I was building). Though it's very possible I did something wrong messing with build settings I generally don't touch

[rlepinski]

I was able to get it to work by setting the Airship's pod project Swift compiler optimization level to optimize for speed and then doing a clean.

[WJacobsNL]

Any workaround when using SPM? Changing the optimization level doesn't seem to do anything for us

[zmknox]

I was able to get it to work by setting the Airship's pod project Swift compiler optimization level to optimize for speed and then doing a clean.

This worked for me too. I think before I was changing the wrong optimization setting.

[rlepinski]

@WJacobsNL You can use the prebuilt SPM packages - https://github.com/urbanairship/ios-library-prebuilt

Its currently for SDK 17 though, its a fairly easy update if you are not deeply integrated with message center - https://github.com/urbanairship/ios-library/blob/main/Documentation/Migration/migration-guide-16-17.md

Most likely its just a few class name changes, updating the deep link listener to be async, and dealing with the new IOS 14+ deployment target

[Dragna]

still the same with Beta 3

here is the stack trace

... multiple other files
/Users/myUser/Developer/iOS/myApp/Pods/Airship/Airship/AirshipCore/Source/Worker.swift
/Users/myUser/Developer/iOS/myApp/Pods/Airship/Airship/AirshipCore/Source/WorkRateLimiterActor.swift
---
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  swift-frontend           0x0000000105bf8a4c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  swift-frontend           0x0000000105bf7f08 llvm::sys::RunSignalHandlers() + 112
2  swift-frontend           0x000000010446b494 SignalHandler(int) + 352
3  libsystem_platform.dylib 0x00000001ab7caa24 _sigtramp + 56
4  libsystem_pthread.dylib  0x00000001ab79bc28 pthread_kill + 288
5  libsystem_c.dylib        0x00000001ab6a9ae8 abort + 180
6  swift-frontend           0x00000001085d85e4 llvm::itanium_demangle::Node* llvm::itanium_demangle::AbstractManglingParser<llvm::itanium_demangle::ManglingParser<(anonymous namespace)::CanonicalizerAllocator>, (anonymous namespace)::CanonicalizerAllocator>::make<llvm::itanium_demangle::EnableIfAttr, llvm::itanium_demangle::NodeArray>(llvm::itanium_demangle::NodeArray&&) + 0
7  swift-frontend           0x0000000105b7b2ec llvm::report_fatal_error(llvm::Twine const&, bool) + 280
8  swift-frontend           0x00000001085b7340 bool llvm::DenseMapBase<llvm::DenseMap<std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>, llvm::GlobalValue*, llvm::DenseMapInfo<std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>, void>, llvm::detail::DenseMapPair<std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>, llvm::GlobalValue*>>, std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>, llvm::GlobalValue*, llvm::DenseMapInfo<std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>, void>, llvm::detail::DenseMapPair<std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>, llvm::GlobalValue*>>::LookupBucketFor<std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>>(std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits> const&, llvm::detail::DenseMapPair<std::__1::pair<clang::CXXRecordDecl const*, clang::CharUnits>, llvm::GlobalValue*> const*&) const + 0
9  swift-frontend           0x00000001040a0eec clang::RecursiveASTVisitor<clang::ParentMapContext::ParentMap::ASTVisitor>::TraverseFixedPointLiteral(clang::FixedPointLiteral*, llvm::SmallVectorImpl<llvm::PointerIntPair<clang::Stmt*, 1u, bool, llvm::PointerLikeTypeTraits<clang::Stmt*>, llvm::PointerIntPairInfo<clang::Stmt*, 1u, llvm::PointerLikeTypeTraits<clang::Stmt*>>>>*) + 0
10 swift-frontend           0x00000001083a3f48 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 224
11 swift-frontend           0x00000001074f6b30 swift::performLLVMOptimizations(swift::IRGenOptions const&, llvm::Module*, llvm::TargetMachine*, llvm::raw_pwrite_stream*) + 4252
12 swift-frontend           0x00000001074f9e38 swift::performLLVM(swift::IRGenOptions const&, swift::DiagnosticEngine&, llvm::sys::SmartMutex<false>*, llvm::GlobalVariable*, llvm::Module*, llvm::TargetMachine*, llvm::StringRef, swift::UnifiedStatsReporter*) + 2736
13 swift-frontend           0x00000001085e3758 generateCode(swift::CompilerInstance&, llvm::StringRef, llvm::Module*, llvm::GlobalVariable*) + 252
14 swift-frontend           0x00000001085ed0ac performCompileStepsPostSILGen(swift::CompilerInstance&, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule>>, llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>, swift::PrimarySpecificPaths const&, int&, swift::FrontendObserver*) + 1708
15 swift-frontend           0x00000001085e8234 performCompile(swift::CompilerInstance&, int&, swift::FrontendObserver*) + 1748
16 swift-frontend           0x00000001085ebba0 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 4216
17 swift-frontend           0x0000000107f47830 swift::mainEntry(int, char const**) + 4112
18 dyld                     0x00000001ab443f28 start + 2236
Command SwiftCompile failed with a nonzero exit code

[rlepinski]

Using the 0 byte file inspection trick to track down the file with the issue, I think I was able to work around the issue.

SDK 17.x - https://github.com/urbanairship/ios-library/commit/28fa3a1965bd0f8ba1a8ae6cf5abf6f87fd5b7a5 branch xcode-15

SDK 16.x - https://github.com/urbanairship/ios-library/commit/c4babdf4099a326b73ca80e8e7229a75ea2b63ca branch xcode-15-SDK16

Could someone in this thread try pointing the SPM package to one of those branches to see if the issue is resolved for you? Once I get confirmation Ill work on releasing a patch.

[borys-tkachenko-hs]

@rlepinski pointing to a SDK 16 commit fixed it for me.

[WJacobsNL]

@rlepinski I tried the xcode-15 branch for sdk 17. It seems to build correctly now :)

[rlepinski]

Thanks!

17.0.3 is out with the fix. Working on a 16.x release

[rlepinski]

Fixed in both 17.0.3 and 16.12.3