Change:
/// this function at a known point where there are no more destructors left /// to run. /// <ins> /// The process's termination will be similar to that from the C `abort()` /// function.  On Unix, the process will terminate with signal `SIGABRT`, which /// typically means that the shell prints "Aborted". /// </ins> /// # Examples /// /// ```no_run

Discussion:
mentions clean ups done by the former that, as far as I know, the latter doesn’t do.
Neither of these perform any cleanups (it's that cleans up, not ). The process version is the platform-specific approach wheras the intrinsics version is the processor-specific approach, typically an illegal instruction.
Perhaps clean-up is not the right word, I was referring to this PR message: The docs already say that Rust destructors are not run.
I believe that's another "forgot to update the PR description with precisely what was merged problem". We don't run cleanups on abort.
Alright, so this is another detail that would be good to clarify in docs.
It's not quite clear to me what we should clarify in docs here. The only thing that I can potentially see is a note on  that it will not run cleanups -- but I'm not sure we should really document intrinsics.
I don’t know what the differences are or what "cleanups" includes exactly. is a case where and are significantly different.
The says that its stabilised version is which is obviouosly not true, because does not call . For those who need a lightweight trap is not suitable.
So if I understand correctly what needs to be done is documenting these two points right?: Document that std::intrinsics::abort uses a processor-specific approach. Document that std::process::abort uses a platform-specific approach. Or do you believe that this distinction should not be documented in the docs? Otherwise we should probably close this issue.
I didn't open this issue, so I'll leave that to although this is a very old issue so it's likely out of cache for everyone involved.
As far as I can tell, on Linux x64 cause a CPU exception which makes the kernel terminate the process, and calls which to trigger the signal which (after possibly running a signal handler) also eventually terminates the process. I don’t know how to document this in a OS- and architecture-independent way, or more importantly why should one be picked over the other.
I just read through the docs of again and it seems that they already make some statements about cleanup: From I guess it might better to no document the platform specifics and rather leave it as it is? That way the function could potentially be implemented differently in the future without people relying on the specific behavior of a certain platform. If you agree we can close this issue!

Could you maybe still respond to my previous comment? Then we can maybe close this issue.
Is there currently no stabilized way to access intrinsics::abort?
Could you maybe still respond to my previous comment? Thanks in advance! There is an issue to stabilize instrinsics::abort here: but the opinions about that different. You can however use . Hope that helps! And sorry for the slow response!
I’m not sure what kind of response you expect :/ In my view we are in either one of two situations: The two functions are fully interchangeable, or one of them is strictly "better" and could be used instead of the other. In this case we would not have a good reason to keep two functions, and could remove one of them. Or, there is some kind trade-off: one function is preferable in some situations and the other in others. In this case I would like to understand how a user should make that choice. If someone can come up with a criteria or an explanation, we could copy that in a doc-comment. And we should stabilize a wrapper for the intrinsic.
I do not know too much about intrinsincs and abort signals sadly. Could you maybe answer the questions of Simon?
These functions are not interchangeable (as pointed out by above). Stable wrappers for isn't easy because it's platform-specific and apparently not all platforms have an abort instruction. This was stabilized as  on wasm and if necessary we'd stabilize on x86/x86_64/etc.
From
People interested in this thread should probably indeed look at my MR which I think deals with many of the things raised here. I have linked this issue so it will be closed by my MR. So please do review my docs proposals.