Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start migrating some Wasmtime crates to no_std #8463

Merged
merged 9 commits into from
Apr 25, 2024

Conversation

alexcrichton
Copy link
Member

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.

@alexcrichton alexcrichton requested review from a team as code owners April 24, 2024 19:59
@alexcrichton alexcrichton requested review from cfallin and fitzgen and removed request for a team April 24, 2024 19:59
@alexcrichton
Copy link
Member Author

I'll also note that, procedurally, my plan is to discuss #8341 in the Wasmtime meeting tomorrow and assuming no objections start landing PRs, but the goal here isn't to jump the gun by any means but rather just be prepared.

@github-actions github-actions bot added the cranelift Issues related to the Cranelift code generator label Apr 24, 2024
@fitzgen fitzgen added this pull request to the merge queue Apr 25, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 25, 2024
@alexcrichton alexcrichton added this pull request to the merge queue Apr 25, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 25, 2024
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 bytecodealliance#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.
@alexcrichton alexcrichton added this pull request to the merge queue Apr 25, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 25, 2024
@alexcrichton alexcrichton added this pull request to the merge queue Apr 25, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 25, 2024
@alexcrichton alexcrichton added this pull request to the merge queue Apr 25, 2024
Merged via the queue into bytecodealliance:main with commit d8f7c77 Apr 25, 2024
48 checks passed
@alexcrichton alexcrichton deleted the initial-no-std branch April 25, 2024 23:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants