cranelift

rust jit wasm webassembly runtime wasi cranelift sandbox wasmtime

Alex Crichton d8f7c77f8f Start migrating some Wasmtime crates to no_std (#8463 ) * Start migrating some Wasmtime crates to no_std This commit is the first in what will be multiple PRs to migrate Wasmtime to being compatible with `#![no_std]`. This work is outlined in #8341 and the rough plan I have in mind is to go on a crate-by-crate basis and use CI as a "ratchet" to ensure that `no_std` compat is preserved. In that sense this PR is a bit of a template for future PRs. This PR migrates a few small crates to `no_std`, basically those that need no changes beyond simply adding the attribute. The nontrivial parts introduced in this PR are: * CI is introduced to verify that a subset of crates can indeed be built on a `no_std` target. The target selected is `x86_64-unknown-none` which is known to not have `std` and will result in a build error if it's attempted to be used. * The `anyhow` crate, which `wasmtime-jit-icache-coherence` now depends on, has its `std` feature disabled by default in Wasmtime's workspace. This means that some crates which require `std` now need to explicitly enable the feature, but it means that by-default its usage is appropriate for `no_std`. The first point should provide CI checks that compatibility with `no_std` indeed works, at least from an "it compiles" perspective. Note that it's not sufficient to test with a target like `x86_64-unknown-linux-gnu` because `extern crate std` will work on that target, even when `#![no_std]` is active. The second point however is likely to increase maintenance burden in Wasmtime unfortunately. Namely we'll inevitably, either here or in the future, forget to turn on some feature for some crate that's not covered in CI checks. While I've tried to do my best here in covering it there's no guarantee that everything will work and the combinatorial explosion of what could be checked in CI can't all be added to CI. Instead we'll have to rely on bug fixes, users, and perhaps point releases to add more use cases to CI over time as we see fit. * Add another std feature * Another std feature * Enable anyhow/std for another crate * Activate `std` in more crates * Fix miri build * Fix compile on riscv64 prtest:full * Fix min-platform example build * Fix icache-coherence again	7 months ago
..
src	Start migrating some Wasmtime crates to no_std (#8463)	7 months ago
Cargo.toml	Leverage Cargo's workspace inheritance feature (#4905)	2 years ago

Start migrating some Wasmtime crates to no_std (#8463 )

* Start migrating some Wasmtime crates to no_std

This commit is the first in what will be multiple PRs to migrate
Wasmtime to being compatible with `#![no_std]`. This work is outlined
in #8341 and the rough plan I have in mind is to go on a crate-by-crate
basis and use CI as a "ratchet" to ensure that `no_std` compat is
preserved. In that sense this PR is a bit of a template for future PRs.

This PR migrates a few small crates to `no_std`, basically those that
need no changes beyond simply adding the attribute. The nontrivial parts
introduced in this PR are:

* CI is introduced to verify that a subset of crates can indeed be
  built on a `no_std` target. The target selected is
  `x86_64-unknown-none` which is known to not have `std` and will result
  in a build error if it's attempted to be used.

* The `anyhow` crate, which `wasmtime-jit-icache-coherence` now depends
  on, has its `std` feature disabled by default in Wasmtime's workspace.
  This means that some crates which require `std` now need to explicitly
  enable the feature, but it means that by-default its usage is
  appropriate for `no_std`.

The first point should provide CI checks that compatibility with
`no_std` indeed works, at least from an "it compiles" perspective. Note
that it's not sufficient to test with a target like
`x86_64-unknown-linux-gnu` because `extern crate std` will work on that
target, even when `#![no_std]` is active.

The second point however is likely to increase maintenance burden
in Wasmtime unfortunately. Namely we'll inevitably, either here or in
the future, forget to turn on some feature for some crate that's not
covered in CI checks. While I've tried to do my best here in covering it
there's no guarantee that everything will work and the combinatorial
explosion of what could be checked in CI can't all be added to CI.
Instead we'll have to rely on bug fixes, users, and perhaps point
releases to add more use cases to CI over time as we see fit.

* Add another std feature

* Another std feature

* Enable anyhow/std for another crate

* Activate `std` in more crates

* Fix miri build

* Fix compile on riscv64

prtest:full

* Fix min-platform example build

* Fix icache-coherence again

7 months ago

src

Start migrating some Wasmtime crates to no_std (#8463)

7 months ago

Cargo.toml

Leverage Cargo's workspace inheritance feature (#4905)

2 years ago