ABANDONED!!! THIS PROGRAM HAS BEEN SUPERCEDED BY igen.

Rust -> Swift IPC Data Schema Translator

Eonil

Generates Swift data-types and serialization code for IPC(inter-process communication) to Rust.

You define data schema in Rust code, and execute this tool to derive corresponding Swift-side data-types and serializations. You can perform Rust-side serializaton with serde. and Swift-side serialization code will be generated.

Intermediate messages will be coded in JSON.

Work Log

syntex_syntax cannot provide fully qualified type info because it does not perform analysis stage. Same for syn. First trial was RLS. I digged into RLS for a few days, and could figure out how it gets type resolution info. It uses save-analysis data emitted by rustc. I tried to use RLS' analysis reading code, but it was too complex and I gave up. Second attemp was rustdoc(now doxidize). It was much simpler and I could see how to read save-analysis data easily using rls-analysis crate. Anyway, rls-analysis has some issue of finding loading path, and I had to move exported save-analysis files to a certain location. Problem continued. I could read the analysis data, but it lacked some important informations (tuple-type enum variant fields defs) It seesm the rls-analysis library is still incomplete and needs more work. Ths only way to fix tihs is updating rustc source code specifically under src/librustc_save_analysis directory. I wouldn't mind contribution, but I discovered that save-analysis facility is actually implemented compiler callback, and actually I can obtain sytax::ast tree (which is same with syntex_syntax).

Then, it seems easier and better to obtain type info from the compiler directly. Because modifying existing codebase is harder than making a new one.

Work Log 2

So far, I'm still failing to get fully qualified type information.

1. syntax or similar parser based approach fails due to lack of type path resolution.

2. save-analysis does not store informations for enum variant fields. I am not sure it actually can provide fully qualified path even if it works.

3. compiler-plugin fails due to lack of type information. HIR tree stores type information as is it appeared in source code, and does not provide fully qualified path even CompileController.after_analysis stage. I'm not sure whether I can get such informations from MIR tree...

4. RLS. I didn't tried this. save-analysis data lacks enum variant informations, where RLS is depending on.

Overall experience is very frustrating. I thought Rust language implementation is matured enough to provide this kind of compiler services because Rust team is working on UX optimizations...

I don't want to re-implement compiler type-resolution logic because it's not future proofing. It seems Rust compiler services is very immature and I have to wait for many years it to get matured.

I stop this trial here. I'm just gonna use Protocol Buffers.

Work Log 3

This program has been superceded by igen.

How to Use

1. Make a root level module named to_swift.
2. Define message data types in there.
3. Execute this tool on Cargo workspace root.

An example is included in source tree.

Type Mappings

Rust to/from 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)

Any other types will not be supported and code-generator will fail with an error.

• All fields must be pub.

• Generated Swift-side serialization code supports only default serde behavior. Any customizations won't work. So DO NOT customize serde behavior to make it work on Swift side.

• Only JSON container protocol is supported. Others maybe work if you can encode/decode them in Swift-side, but haven't been tested.

Goal

• Reliability.
• Simplicity.
• Easeness.

Limitations

• No support for Box type. So no recursive data type.
• No support for HashMap (or any other associated collection) type.

Non-Goal

• Performance. Make it work first.
• Other container protocol else than JSON.
• Generic enum or struct types.
• Nested modules. All types will be placed in flat namespace in Swift.

Constributions and License

Initial version has been written by Eonil. This project is licensed under "MIT License". Any contributions will become same license with this project.