feat: wasm32-wasi target support

[rjzak]

Work-in-progress wasm32-wasi target support for the server feature.

Requires: tokio-rs/tokio#4716

Signed-off-by: Richard Zak [email protected]

[rjzak]

Currently the unit tests fail (even on a clean pull of Hyper and checking out the 0.14.x branch) when using Tokio's main branch. Compiling and testing against tokio = "0.19.2" works fine, but tokio = { git = "http://github.com/tokio-rs/tokio", branch = "master" } has the same errors as compiling and testing against my Tokio wasi_wip branch. I don't know if Tokio is working on breaking changes, or if this is accidental. Seems to be a trait issue:

error[E0599]: the method `read_exact` exists for struct `Rewind<tokio_test::io::Mock>`, but its trait bounds were not satisfied
   --> src/common/io/rewind.rs:132:16
    |
11  | pub(crate) struct Rewind<T> {
    | ---------------------------
    | |
    | method `read_exact` not found for this
    | doesn't satisfy `Rewind<tokio_test::io::Mock>: AsyncReadExt`
    | doesn't satisfy `Rewind<tokio_test::io::Mock>: tokio::io::AsyncRead`
...
132 |         stream.read_exact(&mut buf).await.expect("read1");
    |                ^^^^^^^^^^ method cannot be called on `Rewind<tokio_test::io::Mock>` due to unsatisfied trait bounds
    |
    = note: the following trait bounds were not satisfied:
            `Rewind<tokio_test::io::Mock>: tokio::io::AsyncRead`
            which is required by `Rewind<tokio_test::io::Mock>: AsyncReadExt`
note: the following trait must be implemented
   --> /home/rjzak/.cargo/git/checkouts/tokio-377c595163f99a10/159508b/tokio/src/io/async_read.rs:43:1
    |
43  | / pub trait AsyncRead {
44  | |     /// Attempts to read from the `AsyncRead` into `buf`.
45  | |     ///
46  | |     /// On success, returns `Poll::Ready(Ok(()))` and places data in the
...   |
57  | |     ) -> Poll<io::Result<()>>;
58  | | }
    | |_^

[seanmonstar]

Thanks for hacking away on this! I'm curious, with the split that's currently proposed for hyper 1.0, where hyper no longer directly includes the TcpListener/TcpStream stuff, but rather pushes that to hyper-util, I wonder if that means hyper would need to do anything special. Would that mean the special stuff would only be needed in hyper-util (or perhaps some hyper-wasi crate)?

[rjzak]

How should I proceed? Can we do both, have wasm32-wasi support for the 0.14.x branch, and work on Wasi for the main Hyper branch and Hyper-Util?

The main points:

• Use Tokio with my Wasi PR, which currently requires tokio_unstable. Maybe you want to wait for a new version.
  • h2 needs to also use the correct Tokio
• Disable functions: AddrIncoming::new(), AddrIncoming::bind(), since these aren't allowed on Wasi
• Don't use socket2, since it doesn't support Wasi. Areas where it's used need logic reworked.

I'm also on the Tokio Discord if you'd like to chat there. Definitely want to see this through!

[rjzak]

@seanmonstar Code updated, would like to revisit this. Could the CI run?

[rjzak]

@seanmonstar This should do it, may I have a CI re-run?

[rjzak]

It seems the latest CI run skipped 7 of the tests, and the one which failed was cargo fmt which had the suggested change of:

[rjzak]

The main branch seems to work with Wasi, as cargo test --features=server,http2 --target=wasm32-wasi works. But including feature http1 doesn't since those unit tests use code from the client feature, which don't work with Wasi since Wasi cannot use functions like bind() or connect().

[rjzak]

All tests pass except Miri, and it's not related to my changes; how shall I proceed?

[npmccallum]

@seanmonstar

1. @rjzak Has tested the master branch against wasm32-wasi and has found that it works with --features=server,http2. I've asked him to submit a PR that adds the changes needed to make http1 work and to look at other features.

2. This smallish PR would enabled hyper to work on wasm32-wasi on the 0.14.x branch. This in turn gives us axum support as well as some other notable crates. Given the important position of hyper in the Rust ecosystem, this unlocks a lot of value. Please consider this PR.

[cschramm]

The latest push contains unmerged changes.

[rjzak]

Thanks! So weird that Git and cargo didn't catch that...