Change:
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.

Discussion:
/// Therefore, implementations must not require the user to uphold /// any safety invariants. /// <del> /// A more user-friendly and stable version of this operation is /// [`std::process::abort`](../../std/process/fn.abort.html). </del> <ins> /// [`std::process::abort`](../../std/process/fn.abort.html) is to be preferred if possible, /// as its behavior is more user-friendly and more stable. /// /// The current implementation of `intrinsics::abort` is to invoke an invalid instruction, /// on most platforms. /// On Unix, the /// process will probably terminate with a signal like `SIGABRT`, `SIGILL`, `SIGTRAP`, `SIGSEGV` or /// `SIGBUS`.  The precise behaviour is not guaranteed and not stable. </ins> pub fn abort() -> !; /// Informs the optimizer that this point in the code is not reachable,

/// process, no destructors on the current stack or any other thread's stack /// will be run. /// <ins> /// Rust IO buffers (eg, from `BufWriter`) will not be flushed. /// Likewise, C stdio buffers will (on most platforms) not be flushed. /// </ins> /// This is in contrast to the default behaviour of [`panic!`] which unwinds /// the current thread's stack and calls all destructors. /// When `panic="abort"` is set, either as an argument to `rustc` or in a

/// 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

if error == 0 { Ok(()) } else { Err(crate::io::Error::from_raw_os_error(error)) } } <del> // On Unix-like platforms, libc::abort will unregister signal handlers // including the SIGABRT handler, preventing the abort from being blocked, and // fclose streams, with the side effect of flushing them so libc buffered // output will be printed.  Additionally the shell will generally print a more // understandable error message like "Abort trap" rather than "Illegal // instruction" that intrinsics::abort would cause, as intrinsics::abort is // implemented as an illegal instruction. </del> <ins> // libc::abort() will run the SIGABRT handler.  That's fine because anyone who // installs a SIGABRT handler already has to expect it to run in Very Bad // situations (eg, malloc crashing). // // Current glibc's abort() function unblocks SIGABRT, raises SIGABRT, clears the // SIGABRT handler and raises it again, and then starts to get creative. // // See the public documentation for `intrinsics::abort()` and `process::abort()` // for further discussion. // // There is confusion about whether libc::abort() flushes stdio streams. // libc::abort() is required by ISO C 99 (7.14.1.1p5) to be async-signal-safe, // so flushing streams is at least extremely hard, if not entirely impossible. // // However, some versions of POSIX (eg IEEE Std 1003.1-2001) required abort to // do so.  In 1003.1-2004 this was fixed. // // glibc's implementation did the flush, unsafely, before glibc commit // 91e7cf982d01 `abort: Do not flush stdio streams [BZ #15436]' by Florian // Weimer.  According to glibc's NEWS: // //    The abort function terminates the process immediately, without flushing //    stdio streams.  Previous glibc versions used to flush streams, resulting //    in deadlocks and further data corruption.  This change also affects //    process aborts as the result of assertion failures. // // This is an accurate description of the problem.  The only solution for // program with nontrivial use of C stdio is a fixed libc - one which does not // try to flush in abort - since even libc-internal errors, and assertion // failures generated from C, will go via abort(). // // On systems with old, buggy, libcs, the impact can be severe for a // multithreaded C program.  It is much less severe for Rust, because Rust // stdlib doesn't use libc stdio buffering.  In a typical Rust program, which // does not use C stdio, even a buggy libc::abort() is, in fact, safe. </ins> pub fn abort_internal() -> ! { unsafe { libc::abort() } }