types.rs incompatibility, not clear which should be used

[joepio]

The generated rust-wasmer-runtime/types.rs and rust-plugin/src/types.rs both contain types for the same structs. However, they are not compatible.

When I tried compiling the generated example runtime, cargo was nagging about receiving the wrong ComplexGuestToHost type in rust-wasmer-runtime/bindings.rs. I was able to fix this by changing the imports in rust-wasmer-runtime/bindings.rs, changing them from super::* (which, I assume, links to rust-wasmer-runtime/types.rs) to rust-plugin/src/types.rs.

In my case, I changed my import in my generated runtime to this:

use atomic_bindings::{ComplexAlias, ComplexGuestToHost, ComplexHostToGuest, RequestOptions};

But maybe the real solution is to fix the difference in generated type vs original type. I don't know.

[Zagitta]

You are indeed right that the current example is quite confusing. To a large degree, it's an older approach we don't use ourselves.

What we do instead is have a separate rust crate with the actual types in and mark them with Serializable and tell the code rust code generators to use that type directly instead.
Here's an example of doing that in a crate called my_types

#[derive(Clone, Debug, Deserialize, PartialEq, Serialize, Serializable)]
#[fp(rust_plugin_module = "my_types", rust_wasmer_runtime = "my_types")]
pub struct Foobar {
    pub name: String,
}

This will instead generate a types.rs that looks something like this:

use serde::{Deserialize, Serialize};
use std::{collections::BTreeMap, collections::BTreeSet, collections::HashMap, rc::Rc};

pub use my_types::Foobar;

That behavior is documented in a bit more detail here: https://github.com/fiberplane/fp-bindgen#using-existing-rust-types