std::arch::wasm::unreachable() is stable but does not compile

[eric-seppanen]

I tried to build this code with cargo build --target=wasm32-unknown-unknown:

pub fn force_wasm_trap() {
    std::arch::wasm::unreachable();
}

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:

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

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 both core::arch and std::arch: all fail the same way.

Meta

rustc --version --verbose:

rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1

The same error happens with 1.83.0-beta.5 and nightly-2024-11-12.

[eric-seppanen]

playground link, which also shows the error when set to compile wasm.

[lukas-code]

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.

[SNCPlay42]

The diagnostic could still use improvement to actually indicate which part of the path is the problem.

[eric-seppanen]

Right, got a bit confused about the difference between arch::wasm and arch::wasm32. I will use core::arch::wasm32::unreachable instead.

[eric-seppanen]

I can close this, unless someone wants to hold onto it for docs/diagnostics reasons?

[lukas-code]

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

[CryZe]

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.

[CodesInChaos]

@CryZe the diagnostic improvement would affect all unstable modules, so it'd still be useful if this gets stabilized.

[alexcrichton]

I believe that this is an expected error at the moment, and the appropriate tracking issue for this is over at #90599.