Possible issues when generating Rust bindings

[raif-s-naffah]

Possible problem #1

trying to use the wit-bindgen::generate macro w/ inline source, in service/src/lib.rs like so...

wit_bindgen::generate!({
    inline: r#"
        package wit:api@0.1.0;

        interface hashing {
          hash: func(seed: u32, salt: u32, data: string) -> u32;
        }

        world lib {
          export hashing;
        }
    "#,
    generate_all,
    ownership: Owning,
    pub_export_macro: true,
    raw_strings,
    debug: true,
    async: false,
});

causes rust_analyzer to complain...

[{
	"resource": "/opt/ws-rust/wit-bindgen-issue/service/src/lib.rs",
	"owner": "rust-analyzer",
	"code": {
		"value": "macro-error",
		"target": {
			"$mid": 1,
			"external": "https://rust-analyzer.github.io/book/diagnostics.html#macro-error",
			"path": "/book/diagnostics.html",
			"scheme": "https",
			"authority": "rust-analyzer.github.io",
			"fragment": "macro-error"
		}
	},
	"severity": 8,
	"message": "failed to load file `/opt/ws-rust/wit-bindgen-issue/target/debug/build/wit-bindgen-rust-macro-0d505a222f3682dd/out/lib0.rs`",
	"source": "rust-analyzer",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 23,
	"modelVersionId": 8,
	"origin": "extHost1"
}]

copying the generated Rust code to a file named generated.rs, and replacing the generate macro call w/ that file as its own module seems to solve the problem BUT requires the addition of...

use service::generated::exports as exports;

to the plugin/src/lib.rs source file.

Possible problem #2

sticking w/ the use of the generate! macro w/ inline WIT definition, BUT commenting out the debug field, resolves the above error. however, now...

• the generated source is not accessible/identified.

• in addition, in the plugin crate, the one that implements the WIT Component, the export(MyPlugin) statement should now be replaced w/ export!(MyPlugin with_types_in service).

this too causes rust_analyzer to complain when attempting to implement the Guest component trait...

pub struct MyPlugin;

impl Guest for MyPlugin {
    #[allow(async_fn_in_trait)]
    fn hash(seed: u32,salt: u32,data: _rt::Vec::<u8>,) -> u32 {
        todo!()
    }
}

[{
	"resource": "/opt/ws-rust/wit-bindgen-issue/plugin/src/lib.rs",
	"owner": "rustc",
	"code": {
		"value": "Click for full compiler diagnostic",
		"target": {
			"$mid": 1,
			"path": "/diagnostic message [0]",
			"scheme": "rust-analyzer-diagnostics-view",
			"query": "0",
			"fragment": "file:///opt/ws-rust/wit-bindgen-issue/plugin/src/lib.rs"
		}
	},
	"severity": 8,
	"message": "cannot find module or crate `_rt` in this scope\nif you wanted to use a crate named `_rt`, use `cargo add _rt` to add it to your `Cargo.toml`",
	"source": "rustc",
	"startLineNumber": 7,
	"startColumn": 39,
	"endLineNumber": 7,
	"endColumn": 42,
	"modelVersionId": 27,
	"origin": "extHost1"
}]

--which in a way is understandable, given that the _rt module is private in the service crate.

Worth noting here that the _rt module visibility issue is separate from which export macro variant is used.

[raif-s-naffah]

this is a Rust Workspace project containing both the service as well as the plugin referred to in the previous entry.

wit-bindgen-issues.zip

[alexcrichton]

I'm not personally familiar enough with rust-analyzer to know what's going on here. This looks like it's related to rust-analyzer though and requires more than just this crate itself to be built in a particular way. Someone else may be able to help, but otherwise I'll leave this open since it seems likely a legitimate issue to fix somewhere, but I don't know how or where to fix it myself.

[raif-s-naffah]

thanks @alexcrichton for taking the time to look into this.

i'm not sure how the fact that, for example, the _rt module generated by the macro NOT being public and hence visible to outside crates using the generated code, is related to rustc_analyzer but i don't know enough about this project to challenge this finding.

just to re-iterate, the attached code highlights the issues when defining and generating Rust bindings for one Interface in one crate, then using that in others (one server and two plugins).

i'm happy to provide more info if needed, and try out any patch that addresses those possible issues if indeed they turn out to be bugs.

thanks in anticipation + cheers;
rsn