Skip to content

wit_future FuturePayload implemented for wrong type #1628

Open

Description

@scothis

Using wit-bindgen 0.57.1, I'm implementing a component that interposes wasi:sockets@0.3. Both send and receive on tcp-socket use the return type future<result<_, error-code>>. When implementing these methods, I get the error:

error[E0277]: the trait bound `Result<_, exports::wasi::sockets::types::ErrorCode>: FuturePayload` is not satisfied
    --> src/lib.rs:325:40
     |
 325 |         let (tx, rx) = wit_future::new(|| Err(ErrorCode::Other(None)));
     |                        --------------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `FuturePayload` is not implemented for `Result<_, exports::wasi::sockets::types::ErrorCode>`
     |                        |
     |                        required by a bound introduced by this call
     |
help: the trait `FuturePayload` is implemented for `Result<(), wasi::sockets::types::ErrorCode>`

The FuturePayload trait is implemented for the imported type, but not implemented for the exported type.

If I manually implement the trait for the exported type using the output of cargo expand, replacing the ErrorCode type with the exports version, everything compiles as expected.

The project as a whole is a work in progress, but I can push the code if that helps.

Activity

  1. alexcrichton commented on Jun 8, 2026

    @alexcrichton
    Member

    It looks like this is related to the logic of --merge-structurally-equal-types which I realize isn't being used here but that's the bug, it's leaking out. If you pass --merge-structurally-equal-types you'll generate different bindings but I think that things will work (there'll just be one ErrorCode, not two). Would that work for you for now?

  2. added
    gen-rustRelated to bindings for Rust-compiled-to-WebAssembly
    on Jun 8, 2026
  3. scothis commented on Jun 8, 2026

    @scothis
    ContributorAuthor

    Thanks @alexcrichton. Is it possible to use this setting with the macro instead of the CLI?

    On a side note, reducing the amount of conversation between imported and exported types would be a huge win. I've been tempted to try implementing the From trait for each exported type to allow easier conversions with the equivalent imported type. The two being identical would be even better. For where the types need to be different I could take a stab at implementing something, but will likely need a bit of guidance.

  4. alexcrichton commented on Jun 8, 2026

    @alexcrichton
    Member

    Ah looks like this might not be hooked up to the macro just yet, but that in theory should be relatively easy to do so. Would you be up for sending a PR to do so? And yeah for other conversions that's also reasonable to pley around with, happy to take a look at PRs!

  5. scothis commented on Jun 9, 2026

    @scothis
    ContributorAuthor

    #1633 solves my immediate issue. It's probably worth leaving this issue open since there is an underlying bug.

  6. alexcrichton commented on Jun 9, 2026

    @alexcrichton
    Member

    Agreed yeah, and thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    gen-rustRelated to bindings for Rust-compiled-to-WebAssembly

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions