#swift #ipc #codegen #serialization

nightly app cargo-ipcgen-swift

IPC到Swift的代码生成器

2 个版本

使用旧的 Rust 2015

0.0.1 2018年7月15日
0.0.0 2018年5月15日

#43 in #swift

MIT 许可证

70KB
2K SLoC

废弃!!!该程序已被 igen 取代。

Rust -> Swift IPC 数据模式翻译器

Eonil

生成用于 IPC(进程间通信)的 Swift 数据类型和序列化代码。

您在 Rust 代码中定义数据模式,并执行此工具以推导相应的 Swift 端数据类型和序列化。您可以使用 serde 在 Rust 端执行序列化,并将生成 Swift 端序列化代码。

中间消息将编码为 JSON。

工作日志

syntex_syntax 由于不执行分析阶段,无法提供完全合格的类型信息。同样,syn 也不能。第一次尝试是 RLS。我研究了 RLS 几天,并能够弄清楚它是如何获取类型解析信息的。它使用 save-analysis 数据,这是由 rustc 生成的。我试图使用 RLS 的分析读取代码,但它太复杂了,我放弃了。第二次尝试是 rustdoc(现在 doxidize)。它简单得多,我能够看到如何使用 rls-analysis 包轻松地读取 save-analysis 数据。无论如何,rls-analysis 仍然存在一些查找加载路径的问题,我不得不将导出的 save-analysis 文件移动到特定位置。问题持续存在。我能够读取分析数据,但它缺少一些重要的信息(元组类型枚举变体定义)。似乎 rls-analysis 库仍然不完整,需要更多的工作。唯一解决这个问题的方式是更新 rustc 源代码,具体在 src/librustc_save_analysis 目录下。我不介意贡献,但我发现保存分析功能实际上是编译器回调实现的,实际上我可以获取 sytax::ast 树(与 syntex_syntax 相同)。

然后,从编译器直接获取类型信息似乎更容易更好。因为修改现有代码库比创建一个新的代码库更难。

工作日志 2

到目前为止,我仍然无法获取完全合格的类型信息。

  1. 基于 syntax 或类似解析器的尝试因缺少类型路径解析而失败。

  2. save-analysis不存储枚举变体字段的详细信息。我不确定它即使在正常工作的情况下,是否真的可以提供完全限定的路径。

  3. 由于缺少类型信息,编译器插件失败。HIR树以源代码中出现的原始形式存储类型信息,即使在CompileController.after_analysis 阶段,也不会提供完全限定的路径。我不确定是否可以从MIR树中获得此类信息...

  4. RLS。我没有尝试这个。save-analysis数据缺少RLS所依赖的枚举变体信息。

总体来说,体验非常令人沮丧。我本以为Rust语言实现已经足够成熟,可以提供这种类型的编译器服务,因为Rust团队正在优化用户体验...

我不想重新实现编译器类型解析逻辑,因为它不符合未来的发展方向。看起来Rust编译器服务非常不成熟,我可能需要等待很多年才能使其成熟。

我在这里停止了这个尝试。我打算只使用Protocol Buffers。

工作日志3

此程序已被igen取代。

如何使用

  1. 创建一个名为to_swift的根级别模块。
  2. 在其中定义消息数据类型。
  3. 在Cargo工作区根目录处执行此工具。

源代码树中包含一个示例。

类型映射

Rust到Swift,反之亦然。

std::bool                   <->     Bool
std::i64                    <->     Int64
std::f64                    <->     Float64
std::String                 <->     String
std::option::Option         <->     Optional
std::vec::Vec               <->     Array
(enum)                      <->     (enum)
(struct)                    <->     (struct)

不支持其他类型,代码生成器会因错误而失败。

  • 所有字段都必须是pub
  • 生成的Swift端序列化代码仅支持默认的serde行为。任何自定义都不会工作。因此,不要自定义serde行为以使其在Swift端工作
  • 仅支持JSON容器协议。如果可以在Swift端进行编码/解码,则其他协议可能也可以工作,但尚未经过测试。

目标

  • 可靠性。
  • 简单性。
  • 易于使用。

限制

  • 不支持Box类型。因此没有递归数据类型。
  • 不支持HashMap(或任何其他关联集合)类型。

非目标

  • 性能。首先让它工作。
  • 除JSON之外的容器协议。
  • 泛型enumstruct类型。
  • 嵌套模块。所有类型都将放置在Swift中的扁平命名空间中。

贡献和许可

初始版本由Eonil编写。此项目采用“MIT许可”进行许可。任何贡献都将与本项目采用相同的许可。

依赖关系

~5MB
~100K SLoC