You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
wit_future FuturePayload implemented for wrong type #1628
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.
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?
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.
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!
Activity
alexcrichton commentedon Jun 8, 2026
It looks like this is related to the logic of
--merge-structurally-equal-typeswhich I realize isn't being used here but that's the bug, it's leaking out. If you pass--merge-structurally-equal-typesyou'll generate different bindings but I think that things will work (there'll just be oneErrorCode, not two). Would that work for you for now?scothis commentedon Jun 8, 2026
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.
alexcrichton commentedon Jun 8, 2026
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!
scothis commentedon Jun 9, 2026
#1633 solves my immediate issue. It's probably worth leaving this issue open since there is an underlying bug.
alexcrichton commentedon Jun 9, 2026
Agreed yeah, and thanks!