Xcode crashing if no whole module optimization

[pRizz]

Performing your workaround does not work if whole module optimization is turned off for the desired target. It does work when whole module optimization is on. I would update the instructions to mention this issue. It's probably a moot point since Xcode 7.3 will come out in the next few weeks, fixing this issue anyways. I really appreciate your workaround, by the way! Thanks so much!!!

2016-03-04 01:43:05.627 xcodebuild[30849:1637696]  DVTAssertions: ASSERTION FAILURE in /Library/Caches/com.apple.xbs/Sources/IDELanguageSupport/IDELanguageSupport-9517/XCLanguageSupport/XCSwiftCommandOutputParser.m:230
Details:  (subcommand) should not be nil.
Object:   <XCSwiftCommandOutputParser: 0x7fe613d15d30>
Method:   -handleCommandExitedMessage:didSignal:error:
Thread:   <NSThread: 0x7fe613be1030>{number = 17, name = (null)}
Hints: None
Backtrace:
  0  0x000000010f7f6acd -[DVTAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] (in DVTFoundation)
  1  0x000000010f7f6601 _DVTAssertionHandler (in DVTFoundation)
  2  0x000000010f7f6818 _DVTAssertionFailureHandler (in DVTFoundation)
  3  0x00000001196e618d -[XCSwiftCommandOutputParser handleCommandExitedMessage:didSignal:error:] (in XCLanguageSupport)
  4  0x00000001196e4d33 -[XCSwiftCommandOutputParser handleMessage:error:] (in XCLanguageSupport)
  5  0x00000001196e671a -[XCSwiftCommandOutputParser writeBytes:length:] (in XCLanguageSupport)
  6  0x000000011313935b -[XCLineBufferedOutputStream writeBytes:length:] (in DevToolsCore)
  7  0x00000001131cf43f -[XCWorkQueueCommandSubprocessInvocation handleOutputBytes:length:] (in DevToolsCore)
  8  0x00000001131d17b6 -[XCWorkQueueCommandLocalSubprocessInvocation handleOutputFileDescriptorActivity] (in DevToolsCore)
  9  0x0000000113233cc3 -[Xcode3BuildTask main] (in DevToolsCore)
 10  0x00007fffa0cb52fb -[__NSOperationInternal _start:] (in Foundation)
 11  0x00007fffa0cb4de7 __NSOQSchedule_f (in Foundation)
 12  0x00007fff8acb333f _dispatch_client_callout (in libdispatch.dylib)
 13  0x00007fff8acb7f6f _dispatch_queue_drain (in libdispatch.dylib)
 14  0x00007fff8acbe63b _dispatch_queue_invoke (in libdispatch.dylib)
 15  0x00007fff8acb6c87 _dispatch_root_queue_drain (in libdispatch.dylib)
 16  0x00007fff8acb6a34 _dispatch_worker_thread3 (in libdispatch.dylib)
 17  0x00007fff96f1168f _pthread_wqthread (in libsystem_pthread.dylib)
 18  0x00007fff96f0f365 start_wqthread (in libsystem_pthread.dylib)
Abort trap: 6

[tgebarowski]

Hi,

I know about this issue. My script works only when -Owholemodule is enabled.
I suspect that your crash may be due to: rdar:22858834. At least this is what happens in my project and crashes compilation without -Owholemodule. It is a well known issue also in Xcode 7.3 betas (when you compile without -Owholemodule and use inner classes the compilation crashes on Merging Swift modules). Correct me if this is not your case.

The problem with -Owholemodule is that it is not incremental. So if you have a large project the compilation takes a lot of time, no matter if you change something in your project. I found a workaround for that problem, which works only in Xcode 7.2. First I am using my wrapper script and compile the project with -Owholemodule, then I remove this flag from compiler options and re-run compilation (the wrapper scripts has a separate path when you use it without -Owholemodule). When it is finished I can leverage incremental builds without -Owholemodule. This works until you make some bigger changes in your project (like renaming, deleting files etc.)

Cheers,
Tomasz

[tgebarowski]

Anyway I updated README.md. Thanks for your comment!

[pRizz]

You're welcome Tomasz! And, yes, we do use inner classes in some spots, so that probably explains it.

[tgebarowski]

The bug in swiftc which results in crash when not using -Owholemodule is not that trivial. You have more details in Xcode 7.3 beta 5r elease note (Known issues section) or you can check archive of my twitter account (@tgebarowski). I talked with Apple engineers about it. It is related to usage of inner classes from outside scope.