wit-bindgen icon indicating copy to clipboard operation
wit-bindgen copied to clipboard

Handling of typenames that match Rust typenames

Open tailhook opened this issue 4 years ago • 3 comments

Here is the minimal wit file:

record result {
    data: list<u8>,
}

func: function() -> expected<result, string>

Which yields the following error:

error[E0107]: this struct takes 0 generic arguments but 2 generic arguments were supplied
 --> sdk/src/client.rs:1:1
  |
1 | wit_bindgen_rust::import!("./wit/some.wit");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- help: remove these generics
  | |
  | expected 0 generic arguments
  |
note: struct defined here, with 0 generic parameters
 --> sdk/src/client.rs:1:1
  |
1 | wit_bindgen_rust::import!("./wit/some.wit");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: this error originates in the macro `wit_bindgen_rust::import` (in Nightly builds, run with -Z macro-backtrace for more info)

It wasn't obvious what's going on, but the generated code contains the following:

  pub fn func() -> Result<Result,String>{

We wit-bindgen should either emit some warnings/errors, or perhaps use full paths like ::core::result::Result? The latter is common in macros for any other types, but I think it's not common for Result and Option, so not sure what is the best option.

The issue is pretty minor, though.

tailhook avatar Jan 31 '22 14:01 tailhook

I think the best bet is to probably reference standard rust types through their fully qualified paths instead of assuming the prelude-defined names are the ones that refer to them (e.g. the ::core::result::Result option you mentioned). While a bit of a pain it's generally just generated code so hopefully not the end of the world.

alexcrichton avatar Jan 31 '22 15:01 alexcrichton

It might make sense to implement #54 first and use the scaffolding that gives us to implement this issue.

esoterra avatar Mar 10 '22 02:03 esoterra