Add std::process::abort

[sfackler]

This calls libc abort on Unix and fastfail on Windows, first running
cleanups to do things like flush stdout buffers. This matches with libc
abort's behavior, which flushes open files.

r? @alexcrichton

[alexcrichton]

Looks reasonable to me. I forget, did we decide that we'd only fcp to merge for stabilizations or also new APIs? I think it's the former?

I'd be fine r+'ing if we did indeed conclude there's no need for fcp merge for all new unstable apis.

[alexcrichton]

Oh right, this'll also need a tracking issue before merging

[sfackler]

Tracking issue added.

[brson]

If this is doing the same thing as the std runtime is today then I'm fine landing, if not I'd like to understand the differences.

[sfackler]

Runtime aborts do use abort_internal as well. The only difference here is that we also run cleanups. Not sure if that's something we should do universally, but it definitely seems appropriate for std::process::abort.

[retep998]

abort_internal appears to only be called by sys_common::util::abort which in turn is only called by rtabort!. which in turn is only invoked when unix platforms overflow the stack or if libstd fails to initiate a panic.

There's so many places where Rust calls intrinsics::abort on Windows, even though the current Windows impl of abort_internal would be so much better (because it triggers an unstoppable fast fail exception rather than a confusing illegal instruction exception). We really need an RFC to do a comprehensive cleanup of all the ways that Rust can currently abort.

[alexcrichton]

Looking again at sys_common::cleanup, we may actually want to skip it. It performs tasks like:

• Synchronization via Once
  • May involve thread::park
  • May involve TLS
  • May involve registering TLS depending on the platform
• Cleaning up stored global arguments
• Deregistering stack overflow handlers
• Calling at_exit_imp callbacks
  • This will drop I/O handles and flush stdout/stderr I believe
  • De-initializes windows networking
  • De-initializes and deallocates windows TLS storage tracking.

I think that all of this is relatively dangerous, and optional, to be calling in a context where abort was invoked. These are all very atexit-like things and in C at least abort doesn't execute atexit callbacks unlike the exit function.

[retep998]

This matches with libc abort's behavior, which flushes open files.

On Windows, libc::abort does not actually flush any files. It merely raises the SIGABRT handler if one is registered and then does a __fastfail(FAST_FAIL_FATAL_APP_EXIT);.

[sfackler]

Updated to no longer run cleanups.

[alexcrichton]

@bors: r+

[bors]

📌 Commit fc0140d has been approved by alexcrichton

[bors]

⌛ Testing commit fc0140d with merge 7c535c6...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: alexcrichton
Pushing 7c535c6 to master...