-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
alexcrichton
merged 9 commits into
bytecodealliance:main
from
alexcrichton:initial-no-std
Apr 25, 2024
Merged
Start migrating some Wasmtime crates to no_std #8463
alexcrichton
merged 9 commits into
bytecodealliance:main
from
alexcrichton:initial-no-std
Apr 25, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alexcrichton
requested review from
cfallin and
fitzgen
and removed request for
a team
April 24, 2024 19:59
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
bot
added
the
cranelift
Issues related to the Cranelift code generator
label
Apr 24, 2024
fitzgen
approved these changes
Apr 25, 2024
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 25, 2024
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
force-pushed
the
initial-no-std
branch
from
April 25, 2024 22:08
85c245a
to
62d809b
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 25, 2024
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Apr 25, 2024
prtest:full
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 thatno_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 isx86_64-unknown-none
which is known to not havestd
and will result in a build error if it's attempted to be used.The
anyhow
crate, whichwasmtime-jit-icache-coherence
now depends on, has itsstd
feature disabled by default in Wasmtime's workspace. This means that some crates which requirestd
now need to explicitly enable the feature, but it means that by-default its usage is appropriate forno_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 likex86_64-unknown-linux-gnu
becauseextern 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.