tomaka opened PR #13401 from tomaka:nostd to bytecodealliance:main:
Hello,
Support for
#![no_std]for cranelift is currently broken, and this PR attempts to fix this.I integrated https://github.com/bytecodealliance/wasmtime/pull/12947 for the changes in the frontend crate, alongside with the changes to the CI that were requested in the PR review.
I've also removed the requirement on the
stdfeature ofcranelift-codegen, as otherwisecranelift-frontendautomatically pulls in thisstdfeature.
I did this last change a bit blindly. A quick git blame has led me to https://github.com/bytecodealliance/wasmtime/pull/7369. Unfortunately I don't know enough to know to know whether removing thisstdbreaks anything, nor if it makes sense to leaveunwind.
tomaka requested cfallin for a review on PR #13401.
tomaka requested wasmtime-compiler-reviewers for a review on PR #13401.
tomaka requested alexcrichton for a review on PR #13401.
tomaka requested wasmtime-default-reviewers for a review on PR #13401.
github-actions[bot] added the label cranelift on PR #13401.
:thumbs_up: alexcrichton submitted PR review:
Thanks!
alexcrichton added PR #13401 Restore #![no_std] support for cranelift to the merge queue.
github-merge-queue[bot] removed PR #13401 Restore #![no_std] support for cranelift from the merge queue.
tomaka updated PR #13401.
tomaka commented on PR #13401:
If the CI check did
cargo check -p cranelift-frontend --features core, the CI would pass.But instead of adding
--features core, I think it's a better idea to just make hashbrown non-optional. This means that hashbrown will be an unused dependency when thestdfeature is enabled, but I don't think that this is a problem.
tomaka edited a comment on PR #13401:
If the CI check I've added did
cargo check -p cranelift-frontend --features core, the CI would pass.But instead of adding
--features core, I think it's a better idea to just make hashbrown non-optional. This means that hashbrown will be an unused dependency when thestdfeature is enabled, but I don't think that this is a problem.
tomaka edited a comment on PR #13401:
If the CI check I've added did
cargo check -p cranelift-frontend --features core, the CI would pass.But instead of adding
--features core, I think it's a better idea to just make hashbrown non-optional. This means that hashbrown will be an unused dependency when thestdfeature is enabled, but I personally don't see this as a problem.
alexcrichton added PR #13401 Restore #![no_std] support for cranelift to the merge queue.
github-merge-queue[bot] removed PR #13401 Restore #![no_std] support for cranelift from the merge queue.
tomaka updated PR #13401.
tomaka commented on PR #13401:
I've hopefully fixed the new CI failure :folded_hands:
The code is assuming that
HashMapimplements the serde traits, and with the removal of thestdfeature by default it turns out that it's not the case forhashbrown::HashMap, unless we also requirehashbrown/serde.
tomaka edited a comment on PR #13401:
I've hopefully fixed the new CI failure :folded_hands: Sorry for the back and forth
The code is assuming that
HashMapimplements the serde traits, and with the removal of thestdfeature by default it turns out that it's not the case forhashbrown::HashMap, unless we also requirehashbrown/serde.
alexcrichton added PR #13401 Restore #![no_std] support for cranelift to the merge queue.
:check: alexcrichton merged PR #13401.
alexcrichton removed PR #13401 Restore #![no_std] support for cranelift from the merge queue.
Last updated: Jun 01 2026 at 09:49 UTC