Allow using `demangle` feature in `no_std` builds. (#12740)

While there, add `async`, `debug`, `debug-builtins` and `anyhow` to
the list of features supporting `#![no_std]`, and update the CI job
to

Allow using `demangle` feature in `no_std` builds. (#12740)

While there, add `async`, `debug`, `debug-builtins` and `anyhow` to
the list of features supporting `#![no_std]`, and update the CI job
to include those features.

Signed-off-by: Piotr Sikora <[email protected]>

show more ...

Add book-level documentation for Pulley (#10095)

* Add book-level documentation for Pulley

This commit adds some longer form documentation about Pulley in
Wasmtime's online documentation book. This

Add book-level documentation for Pulley (#10095)

* Add book-level documentation for Pulley

This commit adds some longer form documentation about Pulley in
Wasmtime's online documentation book. This covers topics such as:

* What is Pulley?
* How to enable Pulley?
* What happens when using Pulley.
* Advantages/disadvantages of Pulley.
* High-level design of Pulley.
* Decompiling `*.cwasm` Pulley opcodes.
* Profiling Pulley.

* Update docs/examples-pulley.md

Co-authored-by: Joel Dice <[email protected]>

* Don't test examples

---------

Co-authored-by: Joel Dice <[email protected]>

show more ...

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the previously added `signals-based-traps` feature in
favor of auto-detecting whether it's there or not. The `build.rs`
script for the `wasmtime` crate will now detect the target platform and
auto-enable this feature as necessary.

The `signals-based-traps` cargo feature is removed and split into two
custom `#[cfg]` directives that the build script sets:

* `has_virtual_memory` - this is used to gate mmap implementations for
example. This is enabled on `unix || windows` and will be off for
`no_std` targets for example. This is split out of
"signals-based-traps" to better handle platforms like iOS which have
virtual memory but don't execute native code (removing the need for
native signals).

* `has_native_signals` - gates signal handlers on Unix for example. This
is disabled on MIRI but otherwise enabled for `unix || windows`. This
is intended to in the future get disabled for iOS by default for
example since it's not necessary when using Pulley. This is
additionally off-by-default for `no_std` platforms.

Two new crate features were added for `no_std` or "custom" platforms to
opt-in to the `wasmtime-platform.h` C APIs for implementing virtual
memory and signals. These are used in the `min-platform` embedding example.

This commit additionally updates some various documentation here and
there to be more up-to-date.

* Update CI configuration

* Fix compile warnings

* Fix test on miri

* Fix more tests on miri

* Fix some warnings

* Another round of miri/CI attempts/fixes

prtest:full

show more ...

Update documentation and example for no_std (#8555)

* Update Wasmtime's tier stability documentation

Move some items between tiers and add a few misc items here and there.

* Update platform suppor

Update documentation and example for no_std (#8555)

* Update Wasmtime's tier stability documentation

Move some items between tiers and add a few misc items here and there.

* Update platform support documentation

Re-word lots of this since it was originally written, link to the tiers
of support page, and rewrite the section on `no_std`.

* Update the `min-platform` example with no_std

This commit updates the preexisting `min-platform` example to no longer
require Nightly Rust and instead use the `no_std` support now added to
Wasmtime. This involved:

* Change the build process to produce a staticlib which is then manually
converted via `cc` into a shared library for the native Linux platform.
* Compile the modules outside of the embedding and only `deserialize`
within the embedding.
* Update the `indexmap` dependency to pick up a bug fix required in
`no_std` mode (apparently, it fails on [email protected] and passes at
2.2.6, I didn't dig much further).

This commit additionally makes the `wasmtime-platform.h` header file
generated by the example a release artifact for Wasmtime itself. The
header itself is touched up a bit by configuring some more `cbindgen`
options as well.

* Fix clippy build

prtest:full

* Review comments

* Pass gc-sections to linking the library

show more ...

Add a "custom" platform configuration for Wasmtime (#7995)

* Add a "custom" platform configuration for Wasmtime

This commit leverages adds a new "platform" to Wasmtime to be supported
in the `crate

Add a "custom" platform configuration for Wasmtime (#7995)

* Add a "custom" platform configuration for Wasmtime

This commit leverages adds a new "platform" to Wasmtime to be supported
in the `crates/runtime/src/sys` folder. This joins preexisting platforms
such as Unix and Windows. The goal of this platform is to be an opt-in
way to build Wasmtime for targets that don't have a predefined way to
run.

The new "custom" platform requires `--cfg wasmtime_custom_platform` to
be passed to the Rust compiler, for example by using `RUSTFLAGS`. This
new platform bottoms out in a C API that is intended to be small and
Linux-like. The C API is effectively the interface to virtual memory
that Wasmtime requires. This C API is also available as a header file at
`examples/min-platform/embedding/wasmtime-platform.h` (generated by
`cbindgen`).

The main purpose of this is to make it easier to experiment with porting
Wasmtime to new platforms. By decoupling a platform implementation from
Wasmtime itself it should be possible to run these experiments
out-of-tree. An example of this I've been working on is getting
Wasmtime running on bare-metal with a custom kernel. This support
enables defining the platform interface of the custom kernel's syscalls
outside of Wasmtime.

* Exclude wasmtime-platform.h from formatting

* Include build-wasmtime-target-wasm32 in final job

* Don't force any single toolchain

* Add notes to no_std docs

* Add rust-src to CI

* Review comments

* Change APIs to be fallible

* Only compile the min-platform example on Linux

* Fix compile of min-platform example

* Fix another compile error in the example

show more ...

fix typo in stability-platform-support.md

Expand doc section about "what about `#![no_std]`?" (#2024)

* Expand doc section about "what about `#![no_std]`?"

This commit expands the `#![no_std]` section of the documentation with
an FAQ-st

Expand doc section about "what about `#![no_std]`?" (#2024)

* Expand doc section about "what about `#![no_std]`?"

This commit expands the `#![no_std]` section of the documentation with
an FAQ-style set of words which explains in more detail about why we
don't support `#![no_std]` at this time, and how we can support it in
the future.

* Review comments

* Add some more words about -Zbuild-std

show more ...

Update platform support docs (#2023)

Be sure to mention Linux AArch64 as a supported platform of Wasmtime
now.

Migrate back to `std::` stylistically (#554)

* Migrate back to `std::` stylistically

This commit moves away from idioms such as `alloc::` and `core::` as
imports of standard data structures and

Migrate back to `std::` stylistically (#554)

* 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

show more ...

Add book documentation skeleton and auto-publish from CI (#435)

This commit adds the skeleton of a new set of documentation for
`wasmtime` in the existing `docs` directory. This documentation is
o

Add book documentation skeleton and auto-publish from CI (#435)

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

show more ...