We can build and link just fine, but we cannot actually run the tests as
`wasm-bindgen-test-runner` hasn't yet added support.
Signed-off-by: Joe Richey <joerichey@google.com>
* Cleanup wasm32-wasi target
This change ensures that we only compile our WASI implementation for
32-bit targets. The interaction between the WASI proposal and the
memory64 proposal is not yet clear, [wasmtime does not yet support](
https://github.com/bytecodealliance/wasmtime/issues/3594#issuecomment-992590383)
using WASI with memory64, and many of the interfaces use 32-bit values
for pointers.
This change also reduces the use of `unsafe` from the wasi
implementation. As noted in #253, changes to `Errno` mean that we can't
get the error message from the raw error code, but we can avoid using
unsafe when converting this code to a NonZeroU32. This handling also
makes WASI behave more like our other targets, which also manually check
that errno is non-zero.
Signed-off-by: Joe Richey <joerichey@google.com>
* Disable default features for WASI crate
Similar to this crate, the `wasi` crate just uses a `std` feature to
implement `std::error::Errno`, which we don't use.
Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
* Update to wasi 0.11
The main breaking change between v0.10 and v0.11 is that Error is
removed in favour of Errno. Unfortunately we can't create an Errno from
outside the wasi create so we're loosing some debug information for
errors.
I've opened an issue to add back such a constructor, see
<https://github.com/bytecodealliance/wasi/issues/64>.
* Use libc::strerror to get the error message on wasi
Since wasi v0.11 doesn't (yet) provided a way to create Errno, see
<https://github.com/bytecodealliance/wasi/issues/64>.
* Remove libc dependency for WASI
This does mean that we won't get an error message for the error type.
Add back the "test-in-browser" feature. This makes it easier to manage
a single file containing all of the test code.
Signed-off-by: Joe Richey <joerichey@google.com>
They will be gated behind the "js" feature, as we can now do detect,
at compile-time, which implementation (wasm-bindgen vs stdweb) we
should use.
The "js" implementation takes precedence over the "custom"
implementation. This prevents issues that arise from the buggy way
Cargo handles features across multiple targets.
Signed-off-by: Joe Richey <joerichey@google.com>
This feature isn't enabled by rand/rand_core and provides very little
error information that isn't already conveyed through our Error values.
This also simplifies the supported configuration space for getrandom.
We update the docs and CI to match this change.
