2 个版本
使用旧的 Rust 2015
0.0.1 | 2018年7月15日 |
---|---|
0.0.0 | 2018年5月15日 |
#43 in #swift
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
到目前为止,我仍然无法获取完全合格的类型信息。
-
基于
syntax
或类似解析器的尝试因缺少类型路径解析而失败。 -
save-analysis
不存储枚举变体字段的详细信息。我不确定它即使在正常工作的情况下,是否真的可以提供完全限定的路径。 -
由于缺少类型信息,编译器插件失败。HIR树以源代码中出现的原始形式存储类型信息,即使在
CompileController.after_analysis
阶段,也不会提供完全限定的路径。我不确定是否可以从MIR树中获得此类信息... -
RLS。我没有尝试这个。
save-analysis
数据缺少RLS所依赖的枚举变体信息。
总体来说,体验非常令人沮丧。我本以为Rust语言实现已经足够成熟,可以提供这种类型的编译器服务,因为Rust团队正在优化用户体验...
我不想重新实现编译器类型解析逻辑,因为它不符合未来的发展方向。看起来Rust编译器服务非常不成熟,我可能需要等待很多年才能使其成熟。
我在这里停止了这个尝试。我打算只使用Protocol Buffers。
工作日志3
此程序已被igen
取代。
如何使用
- 创建一个名为
to_swift
的根级别模块。 - 在其中定义消息数据类型。
- 在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之外的容器协议。
- 泛型
enum
或struct
类型。 - 嵌套模块。所有类型都将放置在Swift中的扁平命名空间中。
贡献和许可
初始版本由Eonil编写。此项目采用“MIT许可”进行许可。任何贡献都将与本项目采用相同的许可。
依赖关系
~5MB
~100K SLoC