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!

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.