Stabilize ExitCode::exit_process

[ChrisDenton]

Tracking issue: #97100

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 13 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[clarfonthey]

(we decided we don't need to nominate if we just start FCP)

[ChrisDenton]

I'll start one here too. The first confused libs-fcp member can cancel the other one.

[rust-rfcbot]

@ChrisDenton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @cuviper
• @dtolnay
• @joshtriplett
• @the8472
• @thomcc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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!

cc @rust-lang/libs-ping: FCP proposed for libs, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[ChrisDenton]

For reference I'll copy across my comment from the tracking issue:

I guess my only concern nowadays would be that I'm increasingly wanting people not to use exit_process if they can at all avoid it. Properly exiting from main avoids potential surprises (e.g. drops not being run, TLS fun, unsound atexit, etc).

That said, we do have exit_process already and it does have some use cases so being able to use an ExitCode is better than not being able to.

[clarfonthey]

Yeah, it makes sense to potentially discourage this method + the regular exit via a clippy lint or something, while still allowing it as an option. In particular, this has an advantage over the regular exit since it can forward signals etc. correctly.

[joshtriplett]

I think I must have missed this one when it went by. Not raising a concern (though I might abstain from a checkbox), but:

Why ExitCode::exit_process rather than a standalone function that takes an ExitCode? Very Yoda-like, SUCCESS.exit_process() seems. Proud, Forth would be.

[clarfonthey]

I would imagine that a big motivation is being able to do stuff like command.spawn()?.wait()?.exit_process(), potentially with some extra checking in the middle. The idea of doing ExitCode::SUCCESS.exit_process() feels like a bad idea otherwise.

[ChrisDenton]

Ideally std::process::exit would take an ExitCode. The i32 was a mistake made for historical reasons (IMHO) but not one we can really fix. EDIT: or maybe we can if type inference doesn't bite us. EDIT2: oh there's a From<u8> implementation for ExitCode so I was right the first time, we can't really fix it.

[ChrisDenton]

Ok so counter proposal:

pub fn exit_with<T: Termination>(termination: T) -> ! {
    exit(termination.report().to_i32())
}

Where Termination is the same thing as what is returned from main.