ABANDONED!!! THIS PROGRAM HAS BEEN SUPERCEDED BY 
[`igen`](https://github.com/eonil/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](https://github.com/rust-lang/rust/blob/446aef691e7223f31b18236fb9bf2d08bc25ba46/src/librustc/hir/mod.rs#L620) 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`](https://github.com/eonil/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.