Open eric-seppanen opened 1 week ago
playground link, which also shows the error when set to compile wasm.
This is intentional: The wasm64
intrinsics are still unstable and therefore the std::arch::wasm
and std::arch::wasm64
modules are also unstable. This means that the function std::arch::wasm::unreachable
also isn't be accessible on stable, because a component of the path is still unstable.
The function std::arch::wasm::unreachable
only appears as stable in the docs, because it's a re-export of std::arch::wasm32::unreachable
, which is actually properly stable in 1.37.0 -- The incorrect stability display is a bug that has been fixed and the correct stability will show if you look at the nightly docs of std::arch::wasm::unreachable
.
The diagnostic could still use improvement to actually indicate which part of the path is the problem.
Right, got a bit confused about the difference between arch::wasm
and arch::wasm32
. I will use core::arch::wasm32::unreachable
instead.
I can close this, unless someone wants to hold onto it for docs/diagnostics reasons?
Keeping this open for improving the diagnostic seems reasonable, it would probably help to shorten the span of the path to the segment that's actually unstable:
error[E0658]: use of unstable library feature 'simd_wasm64'
--> src/lib.rs:2:5
|
2 | std::arch::wasm::unreachable();
| ^^^^
|
= note: see issue #90599 <https://github.com/rust-lang/rust/issues/90599> for more information
For more information about this error, try `rustc --explain E0658`.
@rustbot label -C-bug A-diagnostics A-stability D-papercut D-imprecise-spans -needs-triage
Instead of improving the diagnostic, this could also just be stabilized, as the memory64 proposal reached phase 4 and is about to ship in Chrome and Firefox.
@CryZe the diagnostic improvement would affect all unstable modules, so it'd still be useful if this gets stabilized.
I tried to build this code with
cargo build --target=wasm32-unknown-unknown
:I expected to see this happen: compile succeeds, generates a function containing the wasm "unreachable" instruction, which is what the documentation says it does.
Instead, this happened:
I don't understand what happened: the documentation says this has been stable since rust 1.37.0, and I don't think there's any reason why the webassembly "unreachable" instruction would be tied to the unstable "simd_wasm64" feature.
I also tried with and without
#[no_std]
and using bothcore::arch
andstd::arch
: all fail the same way.Meta
rustc --version --verbose
:The same error happens with
1.83.0-beta.5
andnightly-2024-11-12
.