We have started seeing a strange problem, appearing somewhat out of nowhere, where the compiler segfaults in handleDeferredImports. This doesn't always happen, sometimes I need to clean & rebuild 2-3 times to trigger it again, so it's very hard to determine what's the root cause of it.
I've also not been able to reproduce it in a separate sample project, but after two days of looking for solutions I'm drawing a blank.
This is the segfault: error: Segmentation fault: 11 with following stack:
0 swift 0x000000011307064a PrintStackTraceSignalHandler(void*) + 42
1 swift 0x000000011306fdfe SignalHandler(int) + 302
2 libsystem_platform.dylib 0x00007fff76391b3d _sigtramp + 29
3 libsystem_platform.dylib 000000000000000000 _sigtramp + 2311513312
4 swift 0x0000000110605df0 swift::ClangImporter::Implementation::handleDeferredImports() + 512
5 swift 0x00000001106058dc swift::ClangImporter::Implementation::importHeader(swift::ModuleDecl*, llvm::StringRef, swift::SourceLoc, bool, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool) + 1804
6 swift 0x0000000110606754 swift::ClangImporter::importBridgingHeader(llvm::StringRef, swift::ModuleDecl*, swift::SourceLoc, bool, bool) + 932
7 swift 0x000000011010acfd swift::CompilerInstance::performSema() + 2029
8 swift 0x000000010f2f859b performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 731
9 swift 0x000000010f2f4dc5 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 7717
10 swift 0x000000010f29aa35 main + 1349
11 libdyld.dylib 0x00007fff761a808d start + 1
12 libdyld.dylib 0x0000000000000123 start + 2313519255
There's no indication to individual files or headers.
We do use a mix of Objective-C and Swift, importing ProjectModuleName-Swift.h in a lot of files, and similar, have a very large ProjectModuleName-Bridging-Header.h file. In addition to this, for legacy reasons, there's a ProjectModuleName-Prefix.pch for default Objective-C includes (yes, I know that's awful).
What's strange here is the segfault in handleDeferredImports which is different from all the other Swift compiler segfault issues found on Stack Overflow.
Swift version is 4.2, and we're using the "New Build System" in Xcode 10 (it also segfaults on the "Legacy Build System").
Workaround for the Swift 4 compiler was to enable Whole Module optimisation for all builds.
The issue itself appears to been fixed in Swift 5.0
Should anyone see this issue in the future, please refer to https://bugs.swift.org/browse/SR-9528
Related
After upgrading to Xcode 10.2 we cannot compile project anymore. We got this compilation errors. Looks like very wired LLVM compiler error. It is not React Native issue as far as I can see, but I cannot even imagine how to debug this error, there is no information about this in the whole Internet.
May be someone know something about this? Or at least how to debug it? Thanks.
Swift 4.2
React Native 0.59.3 (latest)
Xcode 10.2
Error:
LLVM ERROR: out of memory
Stack dump:
0. Program arguments: <....>
1. While emitting IR SIL function "#$sypSgIegn_Ieg_TR".
for <<debugloc at "<compiler-generated>":0:0>>0 swift 0x000000010b99eee3 PrintStackTraceSignalHandler(void*) + 51
1 swift 0x000000010b99e6bc SignalHandler(int) + 348
2 libsystem_platform.dylib 0x00007fff697f1b3d _sigtramp + 29
3 libsystem_platform.dylib 0x00007ffee848cee0 _sigtramp + 2127147968
4 libsystem_c.dylib 0x00007fff696af1c9 abort + 127
5 swift 0x000000010b94f644 llvm::report_bad_alloc_error(char const*, bool) + 100
6 swift 0x000000010786d210 swift::irgen::CallEmission::setArgs(swift::irgen::Explosion&, bool, swift::irgen::WitnessMetadata*) + 2560
7 swift 0x0000000107a21335 (anonymous namespace)::IRGenSILFunction::visitFullApplySite(swift::FullApplySite) + 2053
8 swift 0x0000000107a016aa swift::irgen::IRGenModule::emitSILFunction(swift::SILFunction*) + 9898
9 swift 0x00000001078c0259 swift::irgen::IRGenerator::emitLazyDefinitions() + 1353
10 swift 0x00000001079e1250 performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, std::__1::unique_ptr<swift::SILModule, std::__1::default_delete<swift::SILModule> >, llvm::StringRef, swift::PrimarySpecificPaths const&, llvm::LLVMContext&, swift::SourceFile*, llvm::GlobalVariable**) + 1232
11 swift 0x00000001078030b9 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 49417
12 swift 0x00000001077f36de swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 6862
13 swift 0x00000001077917be main + 1246
14 libdyld.dylib 0x00007fff69606ed9 start + 1
15 libdyld.dylib 0x000000000000010f start + 2527040055
error: Abort trap: 6
That's somehow is error report of unsupported syntax ¯_(ツ)_/¯
Specifically in our case problem was in new rule for Swift 5 (but we were on Swift 4!):
In Swift 5 mode, #autoclosure parameters can no longer be forwarded to #autoclosure arguments in another function call.
So we've changed:
completionHandler: resolver -> completionHandler: { resolver(nil) }
We've found this problem, when switched to Swift 5 and XCode reported it. Then we switched back to Swift 4 with this fix and everything worked.
I create a cocoatcouch framework, as soon as I add a blank swift file to the project I get an error:
An internal error has occurred. Source editor functionality is limited. Attempting to restore.
The language on the project is set to swift
<module-includes>:1:9: note: in file included from <module-includes>:1:
#import "Headers/Darwin.h"
^
/Users/aryan.ghassemi/Desktop/Darwin/Darwin/Darwin.h:9:9: error: 'UIKit/UIKit.h' file not found
#import <UIKit/UIKit.h>
^
<unknown>:0: error: could not build Objective-C module 'Darwin'
0 swift 0x0000000104cf959a PrintStackTraceSignalHandler(void*) + 42
1 swift 0x0000000104cf8d4e SignalHandler(int) + 302
2 libsystem_platform.dylib 0x00007fff7966eb3d _sigtramp + 29
3 libsystem_platform.dylib 0x00007fd4e542118f _sigtramp + 1809524335
4 swift 0x000000010223504b swift::SerializedModuleLoader::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 891
5 swift 0x000000010237dbb3 swift::ASTContext::getModule(llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 227
6 swift 0x000000010205bf7c swift::performNameBinding(swift::SourceFile&, unsigned int) + 2028
7 swift 0x0000000101d938e3 swift::CompilerInstance::performSema() + 3379
8 swift 0x0000000100f7f50b performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 731
9 swift 0x0000000100f7bd35 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 7717
10 swift 0x0000000100f21965 main + 1349
11 libdyld.dylib 0x00007fff79483ed9 start + 1
12 libdyld.dylib 0x000000000000004c start + 2260189556
Stack dump:
this problem occurs mainly because of multiple XCodes.
Install Command line tool, and try to set the same tool version in below image.
We have recently migrated code from Swift 2.3 to 4.0.
The app working fine when run in debug mode on devices as well as simulators. No issues in compile and build.
But as soon as it is archived, it fails in compilation with the following error. And, more importantly, it is not pointing to any location (no file, no function, no statement) in the code.
Even I am finding difficulty in deducing - where and what the issue is.
It is built using Xcode 9.0. Previously I thought it is the issue of Beta version as I was using the Beta and GM seed of XCode 9.0 on Mac OS Sierra.
Stored value type does not match pointer operand type!
store i64 %119, %swift.bridge** %128, align 8, !dbg !402
%swift.bridge*<unknown>:0: error: fatal error encountered during compilation; please file a bug report with your project and the crash log
<unknown>:0: note: Broken function found, compilation aborted!
0 swift 0x000000010454adba PrintStackTraceSignalHandler(void*) + 42
1 swift 0x000000010454a1f6 SignalHandler(int) + 662
2 libsystem_platform.dylib 0x00007fffacd39b3a _sigtramp + 26
3 libsystem_platform.dylib 0x0000000000000004 _sigtramp + 1395418340
4 libsystem_c.dylib 0x00007fffacbbe420 abort + 129
5 swift 0x0000000100eb9fe7 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*)::$_0::__invoke(void*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, bool) + 551
6 swift 0x00000001045083fb llvm::report_fatal_error(llvm::Twine const&, bool) + 571
7 swift 0x00000001045081ba llvm::report_fatal_error(char const*, bool) + 42
8 swift 0x00000001044de6b6 (anonymous namespace)::VerifierLegacyPass::runOnFunction(llvm::Function&) + 54
9 swift 0x000000010448baaa llvm::FPPassManager::runOnFunction(llvm::Function&) + 506
10 swift 0x0000000104493609 llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 377
11 swift 0x00000001044933fa llvm::legacy::FunctionPassManager::run(llvm::Function&) + 410
12 swift 0x0000000101033778 swift::performLLVM(swift::IRGenOptions&, swift::DiagnosticEngine*, llvm::sys::SmartMutex<false>*, llvm::GlobalVariable*, llvm::Module*, llvm::TargetMachine*, swift::version::Version const&, llvm::StringRef, swift::UnifiedStatsReporter*) + 5016
13 swift 0x00000001010376d5 ThreadEntryPoint(swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int) + 181
14 swift 0x000000010103772f void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int), swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int> >(void*) + 47
15 libsystem_pthread.dylib 0x00007fffacd4393b _pthread_body + 180
16 libsystem_pthread.dylib 0x00007fffacd43887 _pthread_body + 0
17 libsystem_pthread.dylib 0x00007fffacd4308d thread_start + 13
Stack dump:
0. Running pass 'Module Verifier' on function '#_T0s17_dictionaryUpCasts10DictionaryVyq0_q1_GACyxq_Gs8HashableRzsAFR0_r2_lFTfq4g_nSi_SQySayACyS2SGGGSiAHSgTg5'
This is a bug in Swift code generation.
Select Project, go to your desired Target, and under build settings, you may try by changing code optimization level before you compile. Try whole-module-optimization with the respective configuration, as shown below:
With Swift 3.0 this is the default, and Swift 4.0 shouldn't be any different, IMHO.
I went to create a Archive through Xcode and was presented with
Command failed due to signal: Segmentation fault: 11
#selector(NSDecimalNumberBehaviors.scale)
0 swift 0x00000001067b93ad PrintStackTraceSignalHandler(void*) + 45
1 swift 0x00000001067b8b56 SignalHandler(int) + 790
2 libsystem_platform.dylib 0x00007fffd13feb3a _sigtramp + 26
3 swift 0x0000000106722d51 llvm::MCDwarfLineTableHeader::getFile(llvm::StringRef&, llvm::StringRef&, unsigned int) + 3169
4 swift 0x0000000105ae7c38 llvm::DwarfDebug::endModule() + 1080
5 swift 0x0000000105abe571 llvm::AsmPrinter::doFinalization(llvm::Module&) + 2481
6 swift 0x00000001065edee5 llvm::FPPassManager::doFinalization(llvm::Module&) + 53
7 swift 0x00000001065f789b llvm::legacy::PassManager::run(llvm::Module&) + 1803
8 swift 0x000000010391420a performLLVM(swift::IRGenOptions&, swift::DiagnosticEngine&, llvm::sys::SmartMutex<false>*, llvm::GlobalVariable*, llvm::Module*, llvm::TargetMachine*, llvm::StringRef) + 8234
9 swift 0x0000000103910ccb ThreadEntryPoint(swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int) + 171
10 swift 0x0000000103910d53 void* std::__1::__thread_proxy<std::__1::tuple<void (*)(swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int), swift::irgen::IRGenerator*, llvm::sys::SmartMutex<false>*, int> >(void*) + 99
11 libsystem_pthread.dylib 0x00007fffd1408aab _pthread_body + 180
12 libsystem_pthread.dylib 0x00007fffd14089f7 _pthread_body + 0
13 libsystem_pthread.dylib 0x00007fffd14081fd thread_start + 13
The project compiles and runs perfectly fine (Cmd+R)
I've tried:
Clearing the derived data
Rebooting
Searching both Google and SO for any viable options which might match my circumstances.
I've had this before, but have always had some idea of "where" the problem lies, there doesn't seem to be any indication from the stack trace of where to begin to look
The project is (reasonably) large and contains a number of other libraries managed through Carthage, so not easy to post.
I have a "sneaking" suspicion that having opened the project (by mistake) in Xcode 8.3b1 "might" be part of the issue
By following this answer I can make it work, but this is not a long term solution I want to live with.
I know this is long shot and it seems to every question on this has a different cause, but I'd really like to know ANY suggestions that I might look into to solve this issue
TL;DR
Before
SWIFT_WHOLE_MODULE_OPTIMIZATION = NO
Debug compile takes 10-15 minutes
Release compile takes 25+ minutes
po works fine in LLDB
After
SWIFT_WHOLE_MODULE_OPTIMIZATION = YES
Debug compile takes 1-2 minutes
Release compile takes ~8 minutes
po always causes Xcode to crash
Any idea why the horrible compile times based on this info, and/or why Xcode might be crashing?
Deets
I'm working on a large 100% Swift project (there are 3rd party libraries in Objective-C, but all our code is Swift). We have been having atrocious compile times, usually around 10-15 minutes to compile the debug configuration and 30+ minutes to compile the release configuration.
This project has been very difficult to work with because of the horrible compile times. I've been searching for ways to improve this, particularly through build settings and for months had no luck. One thing I overlooked was SWIFT_WHOLE_MODULE_OPTIMIZATION, particularly because any mention of it claims it will increase a project's compile time.
So the other day we enabled SWIFT_WHOLE_MODULE_OPTIMIZATION and lo and behold we have a 10x improvement on compile times.
The problem is, now whenever we're debugging the project and try printing an object in lldb with po myObject Xcode immediately crashes. Here's some info from the crash log:
Process: Xcode [5860]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 6.4 (7720)
Build Info: IDEFrameworks-7720000000000000~8
App Item ID: 497799835
App External ID: 812725084
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Xcode [5860]
Date/Time: 2015-08-05 15:53:08.265 -0600
OS Version: Mac OS X 10.11 (15A235d)
Report Version: 11
Time Awake Since Boot: 13000 seconds
Crashed Thread: 20
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000008f
Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x8f:
-->
__TEXT 000000010ef62000-000000010ef63000 [ 4K] r-x/rwx SM=COW /Applications/Xcode.app/Contents/MacOS/Xcode
Application Specific Information:
ProductBuildVersion: 6E35b
Here's the stack trace on the crashed thread:
Thread 20 Crashed:: <DBGLLDBSessionThread (pid=6402)>
0 com.apple.LLDB.framework 0x0000000116b09ab4 swift::ArchetypeBuilder::resolveArchetype(swift::Type) + 68
1 com.apple.LLDB.framework 0x0000000116b0f808 std::__1::__function::__func<substConcreteTypesForDependentTypes(swift::ArchetypeBuilder&, swift::Type)::$_6, std::__1::allocator<substConcreteTypesForDependentTypes(swift::ArchetypeBuilder&, swift::Type)::$_6>, swift::Type (swift::Type)>::operator()(swift::Type&&) + 152
2 com.apple.LLDB.framework 0x0000000116bc0986 swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 54
3 com.apple.LLDB.framework 0x0000000116bc0f2b swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 1499
4 com.apple.LLDB.framework 0x0000000116bc0bbb swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 619
5 com.apple.LLDB.framework 0x0000000116bc0c0a swift::Type::transform(std::__1::function<swift::Type (swift::Type)> const&) const + 698
6 com.apple.LLDB.framework 0x0000000116b0c8f2 swift::ArchetypeBuilder::substDependentType(swift::Type) + 50
7 com.apple.LLDB.framework 0x0000000116e9554e (anonymous namespace)::LowerType::visitAnyStructType(swift::CanType, swift::StructDecl*) + 270
8 com.apple.LLDB.framework 0x0000000116e92e66 swift::Lowering::TypeConverter::getTypeLoweringForUncachedLoweredType(swift::Lowering::TypeConverter::TypeKey) + 150
9 com.apple.LLDB.framework 0x0000000116e92b39 swift::Lowering::TypeConverter::getTypeLowering(swift::Lowering::AbstractionPattern, swift::Type, unsigned int) + 2361
10 com.apple.LLDB.framework 0x0000000116f8f711 lldb_private::SwiftSILManipulator::emitLValueForVariable(swift::VarDecl*, lldb_private::SwiftExpressionParser::SILVariableInfo&) + 1521
11 com.apple.LLDB.framework 0x00000001172ac7ee (anonymous namespace)::LLDBNameLookup::emitLValueForVariable(swift::VarDecl*, swift::SILBuilder&) + 102
12 com.apple.LLDB.framework 0x0000000116ebb162 swift::Lowering::SILGenFunction::emitInitializationForVarDecl(swift::VarDecl*, swift::Type) + 98
13 com.apple.LLDB.framework 0x0000000116ebbc74 swift::ASTVisitor<(anonymous namespace)::InitializationForPattern, void, void, void, std::__1::unique_ptr<swift::Lowering::Initialization, std::__1::default_delete<swift::Lowering::Initialization> >, void, void>::visit(swift::Pattern*) + 404
14 com.apple.LLDB.framework 0x0000000116ebbc57 swift::ASTVisitor<(anonymous namespace)::InitializationForPattern, void, void, void, std::__1::unique_ptr<swift::Lowering::Initialization, std::__1::default_delete<swift::Lowering::Initialization> >, void, void>::visit(swift::Pattern*) + 375
15 com.apple.LLDB.framework 0x0000000116ebba0d swift::Lowering::SILGenFunction::visitPatternBindingDecl(swift::PatternBindingDecl*) + 45
16 com.apple.LLDB.framework 0x0000000116f0617c swift::Lowering::SILGenFunction::visitBraceStmt(swift::BraceStmt*) + 284
17 com.apple.LLDB.framework 0x0000000116ecd1c0 swift::Lowering::SILGenFunction::emitFunction(swift::FuncDecl*) + 320
18 com.apple.LLDB.framework 0x0000000116ea3966 swift::Lowering::SILGenModule::emitFunction(swift::FuncDecl*) + 246
19 com.apple.LLDB.framework 0x0000000116ea3828 swift::Lowering::SILGenModule::visitFuncDecl(swift::FuncDecl*) + 168
20 com.apple.LLDB.framework 0x0000000116ea579b swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, unsigned int) + 427
21 com.apple.LLDB.framework 0x0000000116ea5c22 swift::SILModule::constructSIL(swift::Module*, swift::SILOptions&, swift::SourceFile*, llvm::Optional<unsigned int>, bool, bool) + 386
22 com.apple.LLDB.framework 0x0000000116ea5d42 swift::performSILGeneration(swift::SourceFile&, swift::SILOptions&, llvm::Optional<unsigned int>, bool) + 98
23 com.apple.LLDB.framework 0x00000001172aa617 lldb_private::SwiftExpressionParser::Parse(lldb_private::Stream&, unsigned int, unsigned int, unsigned int) + 10715
24 com.apple.LLDB.framework 0x000000011706b3e8 lldb_private::ClangUserExpression::Parse(lldb_private::Stream&, lldb_private::ExecutionContext&, lldb_private::ExecutionPolicy, bool, unsigned int) + 1064
25 com.apple.LLDB.framework 0x000000011706cdb4 lldb_private::ClangUserExpression::Evaluate(lldb_private::ExecutionContext&, lldb_private::EvaluateExpressionOptions const&, char const*, char const*, lldb_private::SharingPtr<lldb_private::ValueObject>&, lldb_private::Error&, unsigned int, std::__1::shared_ptr<lldb_private::Module>*) + 628
26 com.apple.LLDB.framework 0x00000001171d1696 lldb_private::Target::EvaluateExpression(char const*, lldb_private::StackFrame*, lldb_private::SharingPtr<lldb_private::ValueObject>&, lldb_private::EvaluateExpressionOptions const&) + 376
27 com.apple.LLDB.framework 0x000000011716d75c lldb_private::SwiftLanguageRuntime::GetObjectDescription(lldb_private::Stream&, lldb_private::ValueObject&) + 668
28 com.apple.LLDB.framework 0x00000001170464e6 lldb_private::ValueObject::GetObjectDescription() + 370
29 com.apple.LLDB.framework 0x000000011548e228 lldb::SBValue::GetObjectDescription() + 76
30 com.apple.dt.dbg.DebuggerLLDB 0x00000001153f3c9e -[DBGLLDBDataValue _lldbValueObjectDescription] + 24
31 com.apple.dt.dbg.DebuggerLLDB 0x00000001153f3b7f -[DBGLLDBDataValue lldbDescription] + 29
32 com.apple.dt.dbg.DebuggerLLDB 0x00000001154023dc __87-[DBGLLDBSession printDescriptionOfDataValueToConsole:runAllThreads:completionHandler:]_block_invoke + 182
33 com.apple.dt.dbg.DebuggerLLDB 0x0000000115402e6d -[DBGLLDBSession handleNextActionWithState:withRunPending:] + 424
34 com.apple.dt.dbg.DebuggerLLDB 0x00000001153fdf44 DBGLLDBSessionThread(void*) + 980
35 libsystem_pthread.dylib 0x00007fff8ec12cb3 _pthread_body + 131
36 libsystem_pthread.dylib 0x00007fff8ec12c30 _pthread_start + 168
37 libsystem_pthread.dylib 0x00007fff8ec10419 thread_start + 13
Seems like we may be on the forefront of new technology here because I haven't found much help on this issue yet. I'm wondering if we have some sort of unusual configuration that is causing the compile time issues, or if there is a known reason why lldb might be crashing. Its the same on multiple different machines, with El Capitan, Yosemite, Xcode 6.3, Xcode 6.4. Any help is appreciated!
I've worked and I am actively working on projects that are probably even larger than yours (50+ libraries, hundreds of custom classes with thousands of LoC). It takes few seconds to compile and up to 2 minutes for release build (Late 2013 MBP), even for full Swift project.
I would highly recommend to look for other causes, as what this option tells you is that your problem is somewhere else since it affects app performance, not building speed. Maybe you have your .pch file full of stuff that does not belong there or something, it can cause this kind of slowing.
Other interesting thing is use of inference. I personally declare type for every single variable just because it is easier to read for others, but there is more to it. Since the inference can get complicated, it can cause compiler to take A LOT of time to figure out what your code actually does. Read this example article, though it was more like alpha-problem. BUT MAYBE, just maybe, you have something like this in your code as well. What would be worth doing is trying to remove all the swift code, compile libraries if that works well, then you know the problem is in your swift code and it will be probably connected to this.
Also, if you provide WHAT actually slows your build time (because you can see whole build process with timestamps, and there is high probability that one step will just take forever), it can help pinpoint the problem more accurately.
Hope it helps!
Edit: Another article on this interested topic
I managed to fix this in our project. (12 mins total compile time)
The key is to set the SWIFT_WHOLE_MODULE_OPTIMIZATION = YES as you say in the user defined settings
But you need to do one more change. You need to set the optimization level to None in debug otherwise you will not be able to debug your app.
I wrote a blog post about it here:
https://tech.zalando.com/blog/improving-swift-compilation-times-from-12-to-2-minutes/