wit_future FuturePayload implemented for wrong type

[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.

[alexcrichton]

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?

[scothis]

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]

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]

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

[alexcrichton]

Agreed yeah, and thanks!