Tracking issue for std::process::abort #37838

Activity

1. sfackler

   added

   B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.

   T-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]

   on Nov 17, 2016
2. alexcrichton commented on Dec 29, 2016

   

   alexcrichton

   on Dec 29, 2016

   Member

   More actions

   @rfcbot fcp merge

   🎉React with 🎉1Reacted by Steve Klabnik
3. rfcbot commented on Dec 29, 2016

   

   rfcbot

   on Dec 29, 2016

   Last edited by brson

   More actions

   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.
4. retep998 commented on Jan 2, 2017

   

   retep998

   on Jan 2, 2017

   Contributor

   More actions

   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.
5. sfackler commented on Jan 19, 2017

   

   sfackler

   on Jan 19, 2017

   MemberAuthor

   More actions

   Ping @brson
6. brson commented on Jan 20, 2017

   

   brson

   on Jan 20, 2017

   Contributor

   More actions

   @retep998 Does that affect your opinion on whether this should be stabilized as-is?
7. retep998 commented on Jan 20, 2017

   

   retep998

   on Jan 20, 2017

   Contributor

   More actions

   @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.
8. sfackler commented on Feb 13, 2017

   

   sfackler

   on Feb 13, 2017

   MemberAuthor

   More actions

   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.
9. rfcbot

   added

   final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.

   on Feb 13, 2017
10. rfcbot commented on Feb 13, 2017

    

    rfcbot

    on Feb 13, 2017

    More actions

    🔔 This is now entering its final comment period, as per the review above. 🔔
11. rfcbot commented on Feb 23, 2017

    

    rfcbot

    on Feb 23, 2017

    More actions

    The final comment period is now complete.
12. SimonSapin commented on Mar 3, 2017

    

    SimonSapin

    on Mar 3, 2017

    Contributor

    More actions

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

    I’ve file a minor docs issue: #40230.
13. alexcrichton commented on Mar 3, 2017

    

    alexcrichton

    on Mar 3, 2017

    Member

    More actions

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

    added a commit that references this issue on Mar 17, 2017

    Stabilize process_abort feature, closes rust-lang#37838

    This issue will close once commit b60879a is merged into the 'master' branch.

    b60879a
15. bors

    closed this as completedin 9511fe6on Mar 19, 2017
16. SimonSapin commented on May 16, 2017

    

    SimonSapin

    on May 16, 2017

    Last edited by SimonSapin

    Contributor

    More actions

    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.