Sourcery项目中AutoMockable模板生成代码的编译问题解析

问题背景

Sourcery是一个强大的Swift代码生成工具，它通过模板引擎自动生成Swift代码。其中AutoMockable模板用于自动生成协议(protocol)的模拟实现(mock)，这在单元测试中非常有用。然而，当前版本的AutoMockable模板在处理包含多个存在性类型(existential type)参数的闭包时，会出现编译错误。

问题现象

当协议方法中包含闭包参数，且该闭包又包含多个使用any关键字声明的存在性类型参数时，生成的模拟类代码会出现括号不匹配的语法错误，导致无法编译。

示例协议定义：

protocol TotoProtocol {
  func execute(completion: ((any StubWithSomeNameProtocol)?, any StubWithSomeNameProtocol) -> (any StubWithSomeNameProtocol)?)
}

错误生成的代码中，闭包类型定义和函数参数列表的括号处理不当，导致语法错误。具体表现为：

1. 闭包类型定义中多余的括号
2. 函数参数列表缺少闭合括号
3. 类型声明格式不正确

技术原理分析

这个问题源于模板引擎对Swift 5.6引入的存在性类型(any关键字)处理不够完善。当遇到嵌套的类型声明，特别是闭包中包含多个存在性类型参数时，模板没有正确识别类型声明的边界，导致生成的代码结构错误。

在Swift中，存在性类型用于表示遵循特定协议的类型，使用any关键字声明。当这些类型出现在闭包参数或返回值中时，类型声明的嵌套层级会变得复杂，需要模板引擎更精确地处理括号匹配。

解决方案

修复方案需要对AutoMockable模板进行以下改进：

1. 修正闭包类型定义的生成逻辑，确保括号正确匹配
2. 正确处理存在性类型在嵌套上下文中的声明
3. 保持原始协议方法签名的精确复制，包括参数和返回值的类型声明

正确的生成结果应该如下所示：

class TotoProtocolMock: TotoProtocol {
  //MARK: - execute

  var executeCompletionAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolVoidCallsCount = 0
  var executeCompletionAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolVoidCalled: Bool {
    return executeCompletionAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolVoidCallsCount > 0
  }
  var executeCompletionAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolVoidClosure: ((((any StubWithSomeNameProtocol)? ,any StubWithSomeNameProtocol) -> (any StubWithSomeNameProtocol)?) -> Void)?

  func execute(completion: ((any StubWithSomeNameProtocol)?, any StubWithSomeNameProtocol) -> (any StubWithSomeNameProtocol)?) {
    executeCompletionAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolVoidCallsCount += 1
    executeCompletionAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolAnyStubWithSomeNameProtocolVoidClosure?(completion)
  }
}

影响范围

这个问题会影响所有使用AutoMockable模板生成模拟类，并且协议方法中包含带有多个存在性类型参数的闭包的情况。在单元测试场景中，这可能导致无法正确生成测试所需的模拟对象。

最佳实践

在使用Sourcery生成模拟类时，建议：

1. 检查生成的代码是否可以编译
2. 对于复杂的类型声明，特别是嵌套的闭包和存在性类型，验证生成的代码是否正确
3. 保持Sourcery和模板文件更新到最新版本
4. 在协议设计时，考虑将复杂的闭包参数类型提取为类型别名(typealias)，提高可读性和生成可靠性

总结

代码生成工具如Sourcery极大地提高了开发效率，但在处理Swift语言的复杂特性时可能会遇到边缘情况。理解这些问题的根源有助于更好地使用工具，并在遇到问题时能够快速定位和解决。对于AutoMockable模板的这个问题，修复后可以确保生成的模拟类正确处理包含多个存在性类型参数的闭包，保证代码的可编译性。