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-bors]

☀️ Try build successful (CI)
Build commit: ab08649 (ab08649c1a84afc9dc34f0ef1fd016d59263b23c, parent: e6b64a2f4c696b840f8a384ec28690eed6a5d267)

[rust-timer]

Finished benchmarking commit (ab08649): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	3
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 0.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.7%	[1.9%, 5.6%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.9%, -1.9%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results (primary 2.2%, secondary 0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.2%	[2.2%, 2.2%]	1
Regressions ❌ (secondary)	4.9%	[2.2%, 8.1%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.7%	[-4.8%, -4.4%]	3
All ❌✅ (primary)	2.2%	[2.2%, 2.2%]	1

Binary size

Results (secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	3
All ❌✅ (primary)	-	-	0

Bootstrap: 487.024s -> 487.341s (0.07%)
Artifact size: 395.12 MiB -> 395.18 MiB (0.02%)

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[jdonszelmann]

not sure I'm the right reviewer for this one, @rustbot reroll

[JohnTitor]

sorry, me neither, @rustbot reroll