Repository navigation
Tracking Issue for std::arch::wasm64 #90599
Description
Activity
- added a commit that references this issue
on Nov 5, 2021 technically this is more than just simd
- changed the title
[-]Tracking Issue for wasm64 SIMD[/-][+]Tracking Issue for std::arch::wasm64 [/+]on Nov 5, 2021 As far as I can tell, the change to make core::arch::wasm unstable was a breaking change (Broke my new project for a nightly user: Craig-Macomber/lol_alloc#1 ) with a really confusing error (Why should using core::arch::wasm require truing on
simd_wasm64to access memory_grow for nightly users when it used to work fine on stable? How is that feature even relevant?).I think we should consider renaming that feature, and/or not disabling the entire core::arch::wasm module with it (as that prevents people from writing wasm target agnostic memory allocators since they can't use core::arch::wasm::memory_grow).
Reacted by Ingvar Stepanyancore::arch::wasmhas always been unstable since it was introduced in 1.58: https://doc.rust-lang.org/1.58.0/src/core/up/up/stdarch/crates/core_arch/src/mod.rs.html#182-185Thats odd. I get no issues using it in
stable-x86_64-unknown-linux-gnu (default) rustc 1.62.1 (e092d0b6b 2022-07-16)with
--target wasm32-unknown-unknown.Maybe there was a bug in marking of aliased paths unstable?
I do get the error if I do
use core::arch::wasm;but not if I douse core::arch::wasm::memory_grow;So it seems like we have three issues:
- The error is bad: this has nothing to do with simd or wasm64:
error[E0658]: use of unstable library feature 'simd_wasm64' --> lol_alloc/src/lib.rs:33:5 | 33 | use core::arch::wasm; | ^^^^^^^^^^^^^^^^-
In some versions of rust, including at least 1.60.0 and 1.60.1, its possible to import children of unstable items without a stability warning: this likely only applies to aliased modules. Apparently this changes (is fixed) in later versions (on nightly). I have not confirmed this change myself.
-
core::arch::wasm::memory_growworks on current stable rust (though it shouldn't), and it does not work on some future version, which is a unintended API breaking change for something that appeared stable.
Reacted by Marcin S.- added 2 commits that reference this issue
on Apr 12, 2026
Feature gate:
#![feature(simd_wasm64)]This is a tracking issue for
std::arch::wasm64andstd::arch::wasmmodules, both of which are currently aliases forstd::arch::wasm32.