Stream: wit-bindgen

Topic: Help with Error type in Rust and error in result.


view this post on Zulip benwis (Feb 24 2024 at 01:02):

I'm trying to write wit definitions to use with wit-bindgen to turn my wasi v1 module into a wasi v2 component, and I'm stumbling on the result type.

I have a Rust function that returns this and the error defined here

wit_bindgen::generate!({
    world: "femark",

    exports: {
        world: MyFemark,
    },
});

struct MyFemark;

impl Guest for MyFemark {
    fn run() {
        print("Hello, world!");
    }

    fn process_markdown_to_html(
        input: String,
    ) -> std::result::Result<HTMLOutput, HighlighterError> {
        process_markdown_to_html(input)
    }

and I tried to define it in wit like so:

// wit/femark.wit
package example:host;

world femark {

  record html-output{
        toc: option<string>,
        content: string,
    }

  /// The set of errors which may be raised by the function
  variant highlightererror {
        model-not-supported,
        runtime-error(string),
        invalid-input(string)
  }

  export process-markdown-to-html: func(input: string) -> result<html-output, highlightererror>;
}

However no matter what combination of things I define, I get errors in validation. Some versions say that I need to make the result type in Rust match Highlightererror. If I do that it complains about conflicting Error impls and duplicate definitions. Any chance someone can point out my mistake?

view this post on Zulip Alex Crichton (Feb 24 2024 at 01:07):

Can you paste the full error message? I can get your example compiling by removing the run function and changing HTMLOutput to HtmlOutput and changing HilighterError to Highlightererror myself

view this post on Zulip benwis (Feb 24 2024 at 01:29):

For full context, the crate I'm trying to get into wasi is here: https://github.com/benwis/femark/tree/wasi
I'm able to compile it into wasi(with some help) by installing the wasi-sdk and building it with RUSTFLAGS='-L /opt/wasi-sdk-21.0/share/wasi-sysroot/lib/wasm32-wasi' CXXSTDLIB=c++ CC=/opt/wasi-sdk-21.0/bin/clang CXX=/opt/wasi-sdk-21.0/bin/clang cargo build --target wasm32-wasi

A Markdown to HTML compiler and Syntax Highlighter, built using Rust's pulldown-cmark and tree-sitter-highlight crates. Compiled for use via the Node FFI. - GitHub - benwis/femark at wasi

view this post on Zulip benwis (Feb 24 2024 at 01:30):

Here is the error I get trying to add the wit-bindgen stuff

error[E0428]: the name `HtmlOutput` is defined multiple times
   --> src/lib.rs:323:1
    |
15  | wit_bindgen::generate!({
    | ----------------------- previous definition of the type `HtmlOutput` here
...
323 | pub struct HtmlOutput {
    | ^^^^^^^^^^^^^^^^^^^^^ `HtmlOutput` redefined here
    |
    = note: `HtmlOutput` must be defined only once in the type namespace of this module

error[E0428]: the name `HighlighterError` is defined multiple times
   --> src/lib.rs:504:1
    |
15  | wit_bindgen::generate!({
    | ----------------------- previous definition of the type `HighlighterError` here
...
504 | enum HighlighterError {
    | ^^^^^^^^^^^^^^^^^^^^^ `HighlighterError` redefined here
    |
    = note: `HighlighterError` must be defined only once in the type namespace of this module

error[E0119]: conflicting implementations of trait `Debug` for type `HighlighterError`
   --> src/lib.rs:503:10
    |
15  | / wit_bindgen::generate!({
16  | |     // the name of the world in the `*.wit` input file
17  | |     world: "femark",
18  | |
...   |
25  | |     },
26  | | });
    | |__- first implementation here
...
503 |   #[derive(Debug, thiserror::Error)]
    |            ^^^^^ conflicting implementation for `HighlighterError`
    |
    = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0119]: conflicting implementations of trait `std::fmt::Display` for type `HighlighterError`
   --> src/lib.rs:503:17
    |
15  | / wit_bindgen::generate!({
16  | |     // the name of the world in the `*.wit` input file
17  | |     world: "femark",
18  | |
...   |
25  | |     },
26  | | });
    | |__- first implementation here
...
503 |   #[derive(Debug, thiserror::Error)]
    |                   ^^^^^^^^^^^^^^^^ conflicting implementation for `HighlighterError`
    |
    = note: this error originates in the derive macro `thiserror::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0119]: conflicting implementations of trait `StdError` for type `HighlighterError`
   --> src/lib.rs:503:17
    |
15  | / wit_bindgen::generate!({
16  | |     // the name of the world in the `*.wit` input file
17  | |     world: "femark",
18  | |
...   |
25  | |     },
26  | | });
    | |__- first implementation here
...
503 |   #[derive(Debug, thiserror::Error)]
    |                   ^^^^^^^^^^^^^^^^ conflicting implementation for `HighlighterError`
    |
    = note: this error originates in the derive macro `thiserror::Error` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0119, E0428.
For more information about an error, try `rustc --explain E0119`.
error: could not compile `femark` (lib) due to 5 previous errors

view this post on Zulip benwis (Feb 24 2024 at 02:08):

I think what's throwing me for a loop right now is that functions are defined in Rust, but possibly the return/input types from those functions are defined in wit and then autogenerated and reused in Rust? So if I want an Error type, I have to accept whatever error type gets generated from the wit binding, and not have my own defined somewhere . Currently I thought the macro was trying to match my rust error type with the wit one, but it sounds like that is not so

view this post on Zulip Christof Petig (Feb 24 2024 at 09:18):

I think you are right that wit-bindgen will unconditionally define its own types and you need to export them to users of your library.

For resources (opaque objects referenced on the other side) at least the host side supports the with keyword to interact with types defined in non-autogenerated code. See this small demo for details.


Last updated: Nov 22 2024 at 16:03 UTC