Async drop fix for async_drop_in_place<T> layout for unspecified T

[azhogin]

Fix for #140423.
Layout of async_drop_in_place<T>::{closure} is calculated for unspecified T from dataflow_const_prop try_make_constant.

@oli-obk, do you think, it may be a better solution to add check like if !args[0].is_fully_specialized() { return None; } in fn async_drop_coroutine_layout?
And could you, pls, recommend, how to implement is_fully_specialized() in a most simple way?

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
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

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[azhogin]

r? oli-obk

[oli-obk]

I think layout_of should bail with TooGeneric if it doesn't have enough information to compute the layout of the async drop in place coroutine. Do we already special case the layout computation of that coroutine or is it going though the default path for coroutines by getting their MIR?

[azhogin]

I think layout_of should bail with TooGeneric if it doesn't have enough information to compute the layout of the async drop in place coroutine. Do we already special case the layout computation of that coroutine or is it going though the default path for coroutines by getting their MIR?

async_drop_coroutine_layout is a special case function called from coroutine_layout.

[azhogin]

coroutine_layout can't return TooGeneric, it returns Option and converts to LayoutError::Unknown in layout_of_uncached. And also coroutine_layout is called from other places. So it requires some re-work to be converted into LayoutError return value.

I added such code to fix the problem:

if args[0].has_placeholders() || args[0].has_non_region_param() {
    return None;
}

[oli-obk]

@bors r+ p=5 blocking beta promotion

[bors]

📌 Commit 13178c7 has been approved by oli-obk

It is now in the queue for this repository.

[oli-obk]

unilaterally accepting for beta promotion as it only affects unstable features

[oli-obk]

And also coroutine_layout is called from other places. So it requires some re-work to be converted into LayoutError return value.

makes sense. Can you do that once this one lands?

[Noratrieb]

@bors p=15 jump ahead of rollups 🚀

[pietroalbini]

Prepared a backport PR in #140918

[bors]

⌛ Testing commit 13178c7 with merge 16c1c54a2921d5ace22e4a71c0ba7d4ef4b8aec7...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 16c1c54 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 9a7e19f (parent) -> 16c1c54 (this PR)

Test differences

Show 2 test diffs

Stage 1

• [ui] tests/ui/async-await/async-drop/open-drop-error.rs: [missing] -> pass (J1)

Stage 2

• [ui] tests/ui/async-await/async-drop/open-drop-error.rs: [missing] -> pass (J0)

Job group index

• J0: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-2, x86_64-gnu, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J1: x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 16c1c54a2921d5ace22e4a71c0ba7d4ef4b8aec7 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-x86_64-apple: 9767.0s -> 7983.3s (-18.3%)
2. x86_64-apple-1: 7022.4s -> 8055.0s (14.7%)
3. x86_64-apple-2: 4978.0s -> 4361.9s (-12.4%)
4. dist-apple-various: 6472.9s -> 6057.3s (-6.4%)
5. dist-aarch64-apple: 4887.9s -> 5198.7s (6.4%)
6. aarch64-gnu: 6273.9s -> 6629.0s (5.7%)
7. dist-various-1: 4709.8s -> 4475.2s (-5.0%)
8. x86_64-gnu-stable: 6382.9s -> 6689.3s (4.8%)
9. x86_64-gnu-aux: 5873.3s -> 6138.5s (4.5%)
10. x86_64-msvc-2: 6675.2s -> 6951.4s (4.1%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (16c1c54): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 0.6%, secondary 3.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.4%, 1.1%]	10
Regressions ❌ (secondary)	4.4%	[2.1%, 5.8%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	0.6%	[0.4%, 1.1%]	10

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 771.266s -> 772.277s (0.13%)
Artifact size: 365.36 MiB -> 365.37 MiB (0.00%)