Feature/revamp host interaction

[tchataigner]

What It Does 🔎

Pull request that changes the way we integrate with an host to send and receive data from a guest wasm module. We leverage pointers on the linear memory of the module.

The objective was to have an integration as light as possible that could be easily integrated on any runtime and allowing for easier updates in the future.

Lets consider a case where we have a transformation named exported and its generated glue code function named wrapped_exported.

From a compiled Wasm stand point, all of our wrapping function that we export to the host will have a signature as such:
fn wrapped_exported(ret_ptr: u32, input_payload_ptr: u32, input_payload_len: u32)

In ret_ptr the Wasm bytecode will store a structure that will store the pointer and length of the return value (a 2 elem tuple of u32) of the exported function.

To make sure that memory is properly handled we also added a function called __hbindgen_mem_alloc that will allocate memory space for each data payload passed from the host to the guest and for the returned structure.

Documentation Updates 📘

N/A

How To Test ✔️

cargo test

Linked Issues 🎫

No tickets linked to this specific development

Related Pull Requests 🔀

• PR about basic integration of runtime in the CLI
• Documentation PR about the SDK

[PhilippeMts]

So nice to see #[holium_bindgen] in action! 🎈
Congrats Thomas!

You will find a few inline comments.

[PhilippeMts]

Thank you for the changes.

You will find a few last comments.

[PhilippeMts]

Thanks Thomas for the update.

• You will find a bit above a comment still opened about ./tests/assets.

• To me, expected and actual versions of export.stderr are still diverging. In fact, differences are now bigger. Here follows the actual output I get:

  error: can't #[holium_bindgen] functions with lifetime or type parameters
    --> $DIR/export.rs:90:13
     |
  90 | pub fn fail3<'a>(x: &'a GoodStruct, y: &'a GoodStruct) -> &'a GoodStruct {
     |             ^^^^
  
  error: can't #[holium_bindgen] functions with lifetime or type parameters
    --> $DIR/export.rs:97:13
     |
  97 | pub fn fail4<T>(x: T) -> T {
     |             ^^^
  
  error[E0277]: the trait bound `BadStructNoMacro: Serialize` is not satisfied
     --> $DIR/export.rs:74:1
      |
  74  | #[holium_bindgen]
      | ^^^^^^^^^^^^^^^^^ the trait `Serialize` is not implemented for `BadStructNoMacro`
      |
     ::: $CARGO/serde_cbor-0.11.2/src/value/ser.rs
      |
      |     T: Serialize,
      |        --------- required by this bound in `to_value`
      |
      = note: required because of the requirements on the impl of `Serialize` for `Vec<BadStructNoMacro>`
      = note: this error originates in the macro `vec` (in Nightly builds, run with -Z macro-backtrace for more info)
  
  error[E0599]: no function or associated item named `generate_node` found for struct `BadStructNoMacro` in the current scope
    --> $DIR/export.rs:74:1
     |
  70 | struct BadStructNoMacro {
     | ----------------------- function or associated item `generate_node` not found for this
  ...
  74 | #[holium_bindgen]
     | ^^^^^^^^^^^^^^^^^ function or associated item not found in `BadStructNoMacro`
     |
     = help: items from traits can only be used if the trait is implemented and in scope
     = note: the following trait defines an item `generate_node`, perhaps you need to implement it:
             candidate #1: `holium_rust_sdk::GenerateNode`
     = note: this error originates in the attribute macro `holium_bindgen` (in Nightly builds, run with -Z macro-backtrace for more info)
  
  error[E0277]: the trait bound `BadStructNoMacro: Serialize` is not satisfied
    --> $DIR/export.rs:74:1
     |
  74 | #[holium_bindgen]
     | ^^^^^^^^^^^^^^^^^ the trait `Serialize` is not implemented for `BadStructNoMacro`
     |
     = note: required by `_::_serde::ser::SerializeStruct::serialize_field`
     = note: this error originates in the derive macro `holium_rust_sdk::internal::serde::Serialize` (in Nightly builds, run with -Z macro-backtrace for more info)
  
  error[E0277]: the trait bound `BadStructNoMacro: Deserialize<'_>` is not satisfied
    --> $DIR/export.rs:74:1
     |
  74 | #[holium_bindgen]
     | ^^^^^^^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `BadStructNoMacro`
     |
     = note: required by `next_element`
     = note: this error originates in the attribute macro `holium_bindgen` (in Nightly builds, run with -Z macro-backtrace for more info)
  
  error[E0277]: the trait bound `BadStructNoMacro: Deserialize<'_>` is not satisfied
    --> $DIR/export.rs:74:1
     |
  74 | #[holium_bindgen]
     | ^^^^^^^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `BadStructNoMacro`
     |
     = note: required by `next_value`
     = note: this error originates in the attribute macro `holium_bindgen` (in Nightly builds, run with -Z macro-backtrace for more info)
  
  error[E0599]: no function or associated item named `generate_node` found for struct `BadStructOnlySerde` in the current scope
    --> $DIR/export.rs:84:1
     |
  80 | struct BadStructOnlySerde {
     | ------------------------- function or associated item `generate_node` not found for this
  ...
  84 | #[holium_bindgen]
     | ^^^^^^^^^^^^^^^^^ function or associated item not found in `BadStructOnlySerde`
     |
     = help: items from traits can only be used if the trait is implemented and in scope
     = note: the following trait defines an item `generate_node`, perhaps you need to implement it:
             candidate #1: `holium_rust_sdk::GenerateNode`
     = note: this error originates in the attribute macro `holium_bindgen` (in Nightly builds, run with -Z macro-backtrace for more info)
  

Tell me if I can help.

[tchataigner]

Okay, the problem for different environment seems to come from the recent release of trybuild. For now I fixed the version of the crate to 1.0.42 where it should work the same on Linux and Windows !

[PhilippeMts]

You are the best !! You will find one last comment.

[tchataigner]

After looking trhough the trybuild crate it seems that the desired workflow was correctly implemented between 1.0.43 and 1.0.49. But this commit in the 1.0.50 seems to have broken the desired flow. An issue is currently opened on the repo so I will bump the version to 1.0.49 and create a ticket to unfreeze dep when the issue is closed.

This path replacement seems to be a big subject in the crate. If not changes seems to come in the following weeks I will open an issue on their repo and maybe open a PR.

[PhilippeMts]

That is perfect, congrats! 🟢