Fix quadratic MIR blowup for large vec![] expressions with Drop-implementing elements in async functions

[jakubadamw]

In #115327, constructing a large Vec<String> inside an async fn used to cause a quadratic blowup in the number of MIR basic blocks, making compilation very slow (minutes for tens of thousands items). Example:

fn main() {
    async_function();
}

async fn async_function() -> Vec<String> {
    vec![
        "string".to_string(), 
        // repeat the above line 10,000 times
    ]
}

The root cause was that StorageDead instructions on the unwind path prevented tail-sharing of drop chains in coroutines. Each element in the vec initialiser got its own unique unwind chain because of distinct StorageDead locals, leading to ~n² basic blocks.

The fix checks whether the coroutine body actually contains any yield points. If there are no yields (e.g. an async fn with no .await), no locals can be live across a yield, so StorageDead on the unwind path can safely be skipped – which restores the tail-sharing and brings MIR size back to linear.

Now, async functions with no await aren’t perhaps necessarily that common, but are sort of inevitable in the case of traits defining a method as async with implementations deciding not to have any yield points for whatever reason.

This PR also adds support for a //@ timeout: N directive to compiletest, so that individual tests can set their own warning timeout (the regression test uses a 10-second timeout to catch any future regressions). This is perhaps controversial or should be separated out into another issue & PR and discussed independently, but I felt like this could be the best way to test this performance improvement. In the future, the compiletest machinery could be made so that the defined timeouts actually lead to an immediate failure rather than merely a warning.

Accordingly, the PR includes a run-make test that compiles a generated async fn returning a vec!["string".to_string(), …] with 10,000 elements, much like the original example from the issue.

I'm not familiar with this part of the compiler so I’d be happy to hear if there's a better way to detect the yield-free case – checking the THIR for ExprKind::Yield seemed like the most straightforward approach, but perhaps there’s a better way?

I guess the PR would deserve a perf run to make sure this doesn’t impact the ”happy path” overly.

Closes #115327.

[rustbot]

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

r? @jdonszelmann

rustbot has assigned @jdonszelmann.
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: compiler, mir
• compiler, mir expanded to 69 candidates
• Random selection from 12 candidates

[matthiaskrgr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[rust-bors]

⌛ Trying commit 55c8a49 with merge ab08649…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/23917572818