Tracking issue for std::process::abort

[sfackler]

Added in #37833

[alexcrichton]

@rfcbot fcp merge

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, 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.

[retep998]

I have just become aware of another function for fatally aborting an application on Windows. FatalAppExit which displays a message box and then terminates, but if a debugger is attached it will give the user the opportunity to debug the error.

[sfackler]

Ping @brson

[brson]

@retep998 Does that affect your opinion on whether this should be stabilized as-is?

[retep998]

@brson If the desired semantics are to abort without informing the user, then the current implementation is fine. If we want to inform the user that the application crashed then FatalAppExit may be a better idea.

[sfackler]

It looks like FatalAppExit can return if the user cancels the dialog box, so if we went that route we'd have to stick a fallback abort after the FatalAppExit call if we went that direction.

[rfcbot]

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

[rfcbot]

The final comment period is now complete.

[SimonSapin]

Is the next step a PR to change #[unstable] to #[stable]?

I’ve file a minor docs issue: #40230.

[alexcrichton]

@SimonSapin yeah that's the next step, we typically do that just before the end of a cycle

[SimonSapin]

For what it’s worth, servo/servo#16899 is a case where process::abort and intrinsics::abort are significantly different.

Calling process::abort from the crash handler causes the crash handler to be invoked again recursively.