This commit uses the `*.witx` files describing the current wasi API to
reduce the boilerplate used to define implementations in the
`wasmtime-wasi` crate. Eventually I'd like to remove lots of boilerplate
in the `wasi-common` crate too, but this should at least be a good start!
The boilerplate removed here is:
* No need to list each function to add it to the
`wasmtime_runtime::Module` being created
* No need to list the signature of the function in a separate
`syscalls.rs` file.
Instead the `*.witx` file is processed in a single-use macro inside the
`wasmtime-wasi` crate. This macro uses the signatures known from
`*.witx` to automatically register with the right type in the wasm
module as well as define a wrapper that the wasm module will call into.
Functionally this is all the same as before, it's just defined in a
different way now!
The shim generated by this macro which wasmtime calls into only uses
`i32`/`i64`/etc wasm types, and it internally uses `as` casts to convert
to the right wasi types when delegating into the `wasi-common` crate.
One change was necessary to get this implemented, however. The functions
in `wasi-common` sometimes took `WasiCtx` and sometimes took a slice of
memory. After this PR they uniformly all require both `WasiCtx` and
memory so the wrappers can be auto-generated. The arguments are ignored
if they weren't previously required.
* Rename the `wasmtime_api` library to match the containing `wasmtime` crate
Commit d9ca508f80 renamed the
`wasmtime-api` crate to `wasmtime`, but left the name of the library it
contains as `wasmtime_api`.
It's fairly unusual for a crate to contain a library with a different
name, and it results in rather confusing error messages for a user; if
you list `wasmtime = "0.7"` in `Cargo.toml`, you can't `use
wasmtime::*`, you have to `use wasmtime_api::*;`.
Rename the `wasmtime_api` library to `wasmtime`.
* Stop renaming wasmtime to api on imports
Various users renamed the crate formerly known as wasmtime_api to api,
and then used api:: prefixes everywhere; change those all to wasmtime::
and drop the renaming.
* Add support for wasi_snapshot_preview1.
This adds support for the new ABI, while preserving compatibility
support for the old ABI.
* Fix compilation on platforms where nlink_t isn't 64-bit.
* rustfmt
* Fix Windows build errors.
* Migrate back to `std::` stylistically
This commit moves away from idioms such as `alloc::` and `core::` as
imports of standard data structures and types. Instead it migrates all
crates to uniformly use `std::` for importing standard data structures
and types. This also removes the `std` and `core` features from all
crates to and removes any conditional checking for `feature = "std"`
All of this support was previously added in #407 in an effort to make
wasmtime/cranelift "`no_std` compatible". Unfortunately though this
change comes at a cost:
* The usage of `alloc` and `core` isn't idiomatic. Especially trying to
dual between types like `HashMap` from `std` as well as from
`hashbrown` causes imports to be surprising in some cases.
* Unfortunately there was no CI check that crates were `no_std`, so none
of them actually were. Many crates still imported from `std` or
depended on crates that used `std`.
It's important to note, however, that **this does not mean that wasmtime
will not run in embedded environments**. The style of the code today and
idioms aren't ready in Rust to support this degree of multiplexing and
makes it somewhat difficult to keep up with the style of `wasmtime`.
Instead it's intended that embedded runtime support will be added as
necessary. Currently only `std` is necessary to build `wasmtime`, and
platforms that natively need to execute `wasmtime` will need to use a
Rust target that supports `std`. Note though that not all of `std` needs
to be supported, but instead much of it could be configured off to
return errors, and `wasmtime` would be configured to gracefully handle
errors.
The goal of this PR is to move `wasmtime` back to idiomatic usage of
features/`std`/imports/etc and help development in the short-term.
Long-term when platform concerns arise (if any) they can be addressed by
moving back to `no_std` crates (but fixing the issues mentioned above)
or ensuring that the target in Rust has `std` available.
* Start filling out platform support doc
* Remove unneded prefix argument from `instantiate_wasi`.
This was an artifact of an earlier backwards-compatibility mechanism
which is no longer needed.
* Remove unneeded prefix arg from remaning uses
* Allow using WASI APIs in the Python extension
This commit adds support to the Python extension to load the WASI
implementation when a WASI module is seen allowing Python to load
WebAssembly modules that use WASI. This is pretty primitive right now
because there's no way to configure the environment/args/preopens/etc,
but it's hoped to be at least a start!
* rustfmt
* Refactor checks for the wasi module name
* Move the check into `wasmtime-wasi` itself
* Make it conservative for now and match anything that says `wasi*`
* Leave a `FIXME` for improving this later on
* Enable missing feature of winapi for `winx`
