While the wasm file has only one export, our introduction should set a
good example for how to find functions even for wasm files that have
multiple exports. Find the answer function by name rather than assuming
index 0.
Minor variable name change to avoid having to wrap the line.
* 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.
* 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
* Cover `cargo wasi`
* Cover a "Hello, world!" binary
* Cover a "Hello, world!" library
* Cover a more advanced example with WebAssembly interface types
* Importing/exporting functionality basics
* Update the top-level README.md and embedding documentation.
wasmtime-api is now the primary external API crate, so recommend that
instead of wasmtime-jit.
Also, enable wasmtime-api's C API by default, so that it shows up on
docs.rs, and to make it easier to use.
And, add basic embedding documentation and link to it from the
README.md. Credit to @yurydelendik for the content.
* Use the new wasm-c-api URL.
* Don't pass --features wasm-c-api, as it is now on by default.
This commit adds the skeleton of a new set of documentation for
`wasmtime` in the existing `docs` directory. This documentation is
organized and compiled with [mdbook] which the Rust project uses for
most of its own documentation as well. At a previous meeting we
brainstormed a rough skeleton of what the documentation in this book
would look like, and I've transcribed that here for an example of how
this is rendered and how it can be laid out. No actual documentation is
written yet.
This commit also additionally adds necessary support to auto-publish
both this book documentation and API documentation every time a commit
is pushed to the `master` branch. All HTML will be automatically pushed
to the `gh-pages` branch so long as the CI passes, and this should get
deployed to https://cranestation.github.io/wasmtime.
I've done a few dry-runs and I think this'll all work, but we'll likely
tweak a few things here and there after running this through CI to make
sure everything looks just as we'd like. My hope though is that after
this lands we can start actually filling out all the documentation and
being able to review it as well.
[mdbook]: https://crates.io/crates/mdbook
I thought it might be useful for future WASI users to have the WASI tutorial written not only in C but also in Rust.
I'm also happy to keep the tutorial up to date with the current state of WASI target in Rust.
Document that `setjmp`/`longjmp` and C++ exceptions are unsupported, and
update the documentation about the function signature mismatch bug to
reflect that it's now just a warning rather than a fatal error.
- Don't include an extra "*" in type of Output arguments.
- Fix the summary of environ_sizes_get.
- Put fs_rights_base and fs_rights_inherinting arguments on separate lines.
- Sort fd_prestat_dirname alphabetically before fd_prestat_get.
Whether the downsides in POSIX and existing application compatibility
outweigh the benefits of thread safety remains an open question.
Right now, this note is just documenting the current behavior.
