Swift compiler segmentation fault when building

I am working with xcode 7.3. Till after noon it was fine. suddenly I started seeing Seg Fault 11 for Objective C style selector.
I don't know know what changed as xcode flipped on me (Of course I didn't update anything). It was literally just next run and it start freaking out.
But I am able to get my project compile after adding #selector in one particular file for which xcode was complaining about.

Weird part is that It's not complaining about other files. It targeted only one file.

My recommendation see what file xcode is complaining about then work on all the warnings that its throwing for swift 3. You might be able to pass this seg fault.

Still at this moment reasons unknown. As I am able to clone the same project else where and compile just fine.

Xcode 8.2.

Adding `@nonobjc` protocol implementation into extension causing segmentation faults.
Move `@nonobjc` protocol implementation into class implementation.

Swift 3.0 (Xcode 8.1) exhibits this issue when a protocol declares an optional variable, and an implementer implements that variable as a lazy initialised one.

Bug is reported here:

[To see links please register here]

I solved it by removing the Build Settings configuration "Objective-C Bridging Header" string I've added manually.

Yet another crash issue:

Variations of the following caused Xcode 8.2b2 compiler crashes in three places in my code:

return self.initialValue.mutableCopy() as AnyObject!

self.initialValue is defined as:

fileprivate let initialValue:AnyObject!

I created various fixes for this, dependent on the context in my code. Here's one of the fixes:

let initialSetValue = self.initialValue as! NSMutableSet
let copy = NSMutableSet(set: initialSetValue);
return copy

When you run into a compiler segfault in Swift, you don't get a handy line number and error message. Here's how you can track the problem down:

1. Create a new file called `SegFaultDebugger.swift` in your project.
2. In this new file, define an extension to the class that's giving you problems.
3. Move a group of methods from the main file to `SegFaultDebugger.swift`.
4. Compile.

At this point, one of three things happens:

* __You still get the segfault in the original file__: Move the methods from `SegFaultDebugger.swift` back to the original file and move a different set of methods into `SegFaultDebugger.swift`. Repeat
* __You get a segfault in `SegFaultDebugger.swift`__: Great! Now use binary search to pin the segfault down to a specific method until you can figure out what construct is causing it.
* __You get meaningful compiler errors__: Great! Fix the errors. Once everything compiles, move your methods back into the original file.

In my case, I had to change from this:

listItem.sortingOrder -= 1

to this:

listItem.sortingOrder = listItem.sortingOrder - 1

I found it by looking at the problematic function (pointed by the build error message `While emitting SIL for 'myBadFunction'`), and taking lines of code one by one until it worked, then focusing on the problematic line of code and trying different things. Good luck.

I got the same error and wasted hours until I saw this blunder in my code:

let databaseRef: FIRDatabaseReference? = FIRDatabase.database().reference()

The problem was `FIRDatabaseReference?`
Changed it to

let databaseRef: FIRDatabaseReference = FIRDatabase.database().reference()

and it started working like a charm! Hope this answer helps!

got this error on Xcode 8 with Swift 3

I had to remove the throws keyword from this:

public extension FileManager {
public func foo() throws -> URLRelationship {
return URLRelationship.other
}
}

to this:

public extension FileManager {
public func foo() -> URLRelationship {
return URLRelationship.other
}
}

In my case, the issue was, that I've had "Math.h" custom file and class in project, importing and using it caused an issue.

The strangest thing, that this file was in project during last 18 days, but everything worked fine. I guess, that it depends on how I'm using it, using it in Objective-C project, doesn't cause any issue.

So it is better to double check classes names.