将扩展移动到主体类之前。

extension SomeType {
// new functionality to add 

}

对我来说(xcode 6.1)，原因是我忘记采用我的子类协议。

例如，这是错误的:

protocol SomeProtocol { ... }
class A :NSObject, SomeProtocol {
...
}
class B : A {
...
}

这是可以的:

protocol SomeProtocol { ... }
class A : NSObject, SomeProtocol {
...
}
class B : A, SomeProtocol {
...
}

我想我找到了一个(可能还有很多)这种情况发生的原因。

在我的例子中，我通过桥接头导入Objective-C文件，桥接头具有以下true之一:

用于Objective-C导入的实现文件(.m)没有 App目标设置正确。 Objective-C文件只有头文件(.h)，而没有 实现(.m)文件。(再一次，我认为这是“不”的一部分 适当的应用目标”设置，因为你只能在。m文件中设置目标 而不是。h文件)

修复Objective-C文件上的应用目标或在桥接头中删除这些文件的导入似乎都可以解决这个问题。

仅供参考-如果你需要设置头(.h)文件的目标，而该文件没有实现(.m)文件，你可以遵循以下简单的步骤

Swift试图动态地而不是静态地找出所有内容的类型，但当它处理复杂类型(如链式过滤器、映射、flatMap调用)或大型字典时，这可能需要付出巨大的努力。有时你需要把它们分开，以便编译器更容易分析。这个问题的一个表亲是“太复杂而不能及时评估”的错误。想象一下，有几个几乎太复杂而无法及时评估的项目:它们一起变成了资源占用者。

试着找到所有您创建动态字典或使用无类型调用链的地方。尝试更具体地输入，特别是在变量声明处。

一些简单的例子:

字典

Bad:

let myDict = [ /* bunch of different things */ ]

好:

let myDict: [String: AnyObject] = [ /* bunch of different things */ ] 

最好的:

let myDict: [String: SpecificType] = [ /* bunch of similar things */ ]

映射

Bad:

let filteredUserIds = users.filter({ user in user.enabled })
    .flatMap { user in user.name != nil ? return user.id : return nil }

好:

let filteredUserIds: [Int] = users.filter({ user in user.enabled })
    .flatMap { user in user.name != nil ? return user.id : return nil }

最好的:

let enabledUsers: [User] = users.filter { user in user.enabled } 
let filteredUserIds: [Int] = enabledUsers.flatMap { 
    user in user.name != nil ? return user.id : return nil 
}

好处还包括额外的检查代码，因为您总是会得到预期的类型或编译器错误。缺点是它开始看起来有点像Java。

当然，随着项目的发展，这个问题首先会积累起来。小型Swift项目总是很快。所以可能有很多工作要做。经验告诉我们哪些表达是复杂且耗时的。如果你能对这些事情进行基准测试，那就太好了。

你的项目叫Swift吗?看到这个消息，构建也会失败(<unknown>:0: error:模块名“Swift”是为标准库保留的)。尝试使用其他项目名称，例如SwiftTest。它会起作用的。

我在苹果的开发者论坛上找到了一个解决方案(需要登录，所以我也会在这里解释)。

TLDR:不要在Objective-C中导入与@interface同名的@protocol到Swift桥接头。例如，Facebook SDK有一个名为“FBGraphObject”的协议和接口。

以下是论坛帖子:

Adding Facebook SDK causes SourceKitService to crash. If you want to use beta 3 and you need Facebook SDK, one work around that I found and is working for me is refactoring Facebook SDK's @protocol FBGraphObject and renaming it to something like @protocol FBGraphObjectProtocol as an @interface FBGraphObject also exists and apparently SourceKit doesn't like it. It sure is a temporary solution just to keep you functional and you'll have to use Cocoapods or otherwise build Facebook SDK yourself rather than using the framework library. For the time being, you'll need to make sure you don't have conflicting @protocol and @interface declarations and that includes 3rd party libraries you may be using. This cost me today, hope it helps! Posted by e.parto on July 10, 2014