Stabilize std::arch::wasm32::unreachable

[pepyakin]

This is a tracking issue to stabilize std::arch::wasm32::unreachable
The tentative signature is:

fn unreachable() -> !;

Semantics

This intrinsic represents instruction that is present in the MVP of WebAssembly: unreachable.

From the surface it is a simple instruction: it doesn't take any arguments nor return anything. Upon the execution it generates a trap, which terminates the execution of wasm immediately returning control to the embedder with an error. There are no way to catch a trap at the moment.

Note that technically a WebAssembly instance can be used after a trap. However, Rust doesn't guarantee that such a module is usable after a trap. For example, there is no guarantee that the stack will be reset to initial values or that any destructors be executed.

Stabilization in Rust

In a way, this intrinsic is similar to the currently stabilized std::process::abort function. In fact, std::process::abort is lowered to the unreachable instruction for wasm32-unknown-unknown - this is totally makes sense since wasm32-unknown-unknown doesn't make any assumptions of the host environment. However, there is a problem with std::process::abort, it is only available in std. Consider how you would implement a panic handler in WebAssembly for no_std mode when a trap is required:

#[panic_handler]
fn panic_handler(_: &PanicInfo) -> ! {
    unsafe {
        intrinsics::abort();
    }
}

This works, however, it requires #![feature(core_intrinsics)]. Here are other ways and why they are not appropriate:

1. e.g. safe division by zero - requires panic, thus recursive. Unsafe division might work, but then it would require loop { } which might be a problem.
2. e.g. make an access to the address 0xFFFFFFFF assuming that it is not accessible. Doesn't work if the module genuinely allocates 4GiBs. I guess that optimizer also might be able to figure out that it is being tricked with respective consequences.
3. e.g. call_indirect suffer from the similar issues.
4. If the host is known (which is likely), it might be possible to introduce a special host function sole function of which is just trap. But that feels hacky and clumsy as well.

Stabilization of unreachable will allow implementing the panic handler in no_std environments on stable.

cc @alexcrichton @sunfishcode

[alexcrichton]

@rfcbot fcp merge

Seems reasonable to me to stabilize!

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[SimonSapin]

Is this the same as core::intrinsics::abort? Should we have a stable portable function for this in libcore?

[alexcrichton]

It is indeed the same, but there have been concerns about stabilizing intrinsics::abort historically due to some architectures not actually having an abort instruction (I think it was like msp430 or something like that)

[pepyakin]

I guess almost all of MCUs don't have such an instruction. Maybe @japaric can confirm this?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[alexcrichton]

Ok great! @pepyakin want to send a PR to stabilize to stdsimd?

[est31]

I think this can be closed @alexcrichton