Tracking Issue for std::arch::wasm64

[Amanieu]

Feature gate: #![feature(simd_wasm64)]

This is a tracking issue for std::arch::wasm64 and std::arch::wasm modules, both of which are currently aliases for std::arch::wasm32.

[devsnek]

technically this is more than just simd

[Craig-Macomber]

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_wasm64 to 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).

[Amanieu]

core::arch::wasm has 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-185

[Craig-Macomber]

Thats 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 do use core::arch::wasm::memory_grow;

So it seems like we have three issues:

1. 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;
   |     ^^^^^^^^^^^^^^^^

2. 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.

3. core::arch::wasm::memory_grow works 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.

[Amanieu]

I believe the stricter checking of stability was introduced by #95956.

Can you open a separate issue for this? This issue is for tracking the stabilization of the wasm64 intrinsics.