MCP: Add -Zasync-panic for binary size

Proposal

Part of project goal Async statemachine optimisation

I want to add a way for users to optimize statemachines by removing panic paths.
Currently all generated futures will panic when it's poisoned or when it has returned Ready before.
This is good and should remain the default.

However, this has a cost. These branches of the statemachines are never hit in code that is bug free. But LLVM does not know this and can't/won't optimize these panics away. The presence of the panics means LLVM needs to be pessimistic with other optimizations.

Removing the panics and replacing them with simply returning Pending reduces the binary size by about 2% (and up to 5%) on async embedded firmware applications.

I've implemented it here on my fork already: https://github.com/rust-lang/rust/compare/main...diondokter:rust:async-panic
I'm submitting this MCP following the guide here: https://forge.rust-lang.org/compiler/proposals-and-stabilization.html?highlight=unstable%20flag#compiler-flags

Returning Pending is legal I think. The reference doesn't say async blocks or async fns are guaranteed to panic and the Future docs only mention that the behavior is unspecified, but must be 'safe'.

The end goal is getting this flag stabilized as a profile option in cargo. (Possibly with panics off by default in release mode, but that can be discussed then)

Maybe there should be some bikeshedding on the name? Alternatives I can think of:

• coroutine-panic
• async-panics

Or maybe it should be an enum?

• async-poll-after-completion = "panic" / "pending"

Mentors or Reviewers

Review of the PR for the flag can likely be done by @dingxiangfei2009

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

No repository files or tests are named. Start by reviewing the linked fork comparison and the Future panic documentation, then examine the proposed flag's compiler behavior and binary-size measurements. Done means the proposal's semantics, name, and approval path are resolved through the compiler team's MCP process.