(#1161) - Introduce 'rust.eo' & 'ffi.eo'

[andreoss]

Per #1161

• Add rust.eo and ffi.eo
• Add to-rust.xsl
• Add todos

[yegor256]

@andreoss I don't think there should be language-level support of this rust object. This object should be just as normal as all others. The implementation of it will do all the magic.

[andreoss]

@yegor256 What do you mean by language-level? rust object is just an array right now, I guess it can have method-objects like as-int, as-bytes, etc, which could be added to ffi.eo later. to-java.xsl will generate new PhNative(...) to-rust.xsl will add <rust>...</rust> to xml BinarizeMojo will extract source code, compile it and put object files to eo-binary. these files will be loaded and executed with PhNative

[yegor256]

@andreoss why do we need PhNative and why we need <rust> inside XMIR? Our BinarizeMojo will just find <o base="org.eolang.rust"> elements in XMIR, extract Rust code from them, compile Rust into .so and that's it. Then, in runtime, EOorg.EOeolang.EOrust object will find the necessary .so file in classpath and will execute it.

[andreoss]

@yegor256

why we need inside XMIR?

It's not part of XMIR, in the same way as <java> it will be erased from final XML.

why do we need PhNative?

I guess it has to be similar to how Java code is generated.

1. EOrust implemented in Java would not be able to know the name of produced file, package, etc.
2. We have parameters (dependecies, versions) which should be available for Mojo (and eventually passed to rustc), the only way to access them right now is via XSL (JavaFiles class works that way).
3. I'm not sure if the same method can call several native libraries, i.e native method is linked only once with a shared library, need to check that. If it's so, PhNative will be useful as a base class for a generated wrapper

[yegor256]

@andreoss your approach is doable, but it seems too complex to me. We can reduce the amount of meta information. Again, BinarizeMojo can take everything that is needed right from XMIR. No need to create additional <rust> element and have an additional XSL for it. We just simply find Rust pieces and compile them into target/classes/eo-binaries. Then, in runtime we link to those .so files and call them (yes, it's possible in Java).

[andreoss]

@yegor256

Then, in runtime we link to those .so files and call them (yes, it's possible in Java).

I will check that. System.loadLibrary should be called in static context, and the library will not be unloaded until the class reference is garbage-collected. Also, at least for j4rs there should a native method for each rust function

[yegor256]

@andreoss we will ALWAYS have only one Rust function per .so file with always the same signature

[andreoss]

@yegor256 Please take a look again

[yegor256]

@andreoss see above

[yegor256]

@andreoss all looks good now, but I believe we need a @todo for the rust.eo object (or its test)

[andreoss]

@yegor256 please, take a look again

[yegor256]

@rultor merge

[rultor]

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

[rultor]

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 7min)