2 releases
Uses old Rust 2015
0.0.1 | Jul 15, 2018 |
---|---|
0.0.0 | May 15, 2018 |
#43 in #swift
70KB
2K
SLoC
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.
-
syntax
or similar parser based approach fails due to lack of type path resolution. -
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. -
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... -
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
- Make a root level module named
to_swift
. - Define message data types in there.
- 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 customizeserde
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
orstruct
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.
Dependencies
~5MB
~100K SLoC