Always make tuple elements a coercion site by WaffleLapkin · Pull Request #147834 · rust-lang/rust

WaffleLapkin · 2025-10-17T22:57:57Z

Previously we only used check_expr_coercible_to_type if we had an expectation (using check_expr_with_expectation(NoExpectation) otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we do insert it eagerly, so this prevents some code from compiling, for example:

((),) = (loop{},);

With this PR we are always using check_expr_coercible_to_type (using an infer var if there is no expectation), which allows slightly more code to compile.

Fixes#112856

r? BoxyUwU

rustbot · 2025-10-17T22:58:01Z

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

BoxyUwU · 2025-10-25T12:40:37Z


+ /// Returns a list of tuple type arguments, or `None` if `self` isn't a tuple.
+ #[inline]
+ pub fn tuple(self) -> Option<&'tcx List<Ty<'tcx>>> {


Suggested change
pubfntuple(self) -> Option<&'tcxList<Ty<'tcx>>>{
pubfnopt_tuple_fields(self) -> Option<&'tcxList<Ty<'tcx>>>{
seems like it does the same thing as tuple_fields it just doesnt panic

That is indeed the case, is there a problem with that? In the code I wrote I found this a lot more convenient than checking the type first.

no it's fine I just found the differences in the names doesn't really reflect the differences in behaviour

If you have a better idea for the names I can rename them

i suggested a different name already :P

🤦🏻
I swear I sleep at night sometimes

BoxyUwU · 2025-10-25T13:18:07Z

@bors try @rust-timer queue

should crater this as it is theoretically breaking, though I don't actually expect any breakage here 🤔

Always make tuple elements a coercion site

BoxyUwU · 2025-10-25T13:19:55Z

When we stabilize the never type do we intend to change how NeverToAny coercions work? Will we continue unconditionally coercing ! to an inference variable, or will we stop doing that? Or in other words, is the stable behaviour here the behaviour we'd expect to have once never type is stabilized?

rust-bors · 2025-10-25T15:30:25Z

☀️ Try build successful (CI)
Build commit: f77b5bc (f77b5bc6c7c84df104f86b0dd01d9490e3923fa8, parent: 04ff05c9c0cfbca33115c5f1b8bb20a66a54b799)

rust-timer · 2025-10-25T16:55:48Z

Finished benchmarking commit (f77b5bc): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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.1%	[0.1%, 0.2%]	3
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	1
All ❌✅ (primary)	0.1%	[0.1%, 0.2%]	3

Max RSS (memory usage)

Results (primary 1.4%, secondary -1.2%)

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

	mean	range	count
Regressions ❌ (primary)	1.4%	[0.8%, 2.1%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	1.4%	[0.8%, 2.1%]	2

Cycles

Results (primary -2.1%, secondary -3.8%)

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)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-3.8%	[-5.3%, -2.1%]	4
All ❌✅ (primary)	-2.1%	[-2.1%, -2.1%]	1

Binary size

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

Bootstrap: 473.373s -> 475.58s (0.47%)
Artifact size: 390.48 MiB -> 390.48 MiB (-0.00%)

BoxyUwU · 2025-10-25T23:37:26Z

@craterbot check

craterbot · 2025-10-25T23:37:54Z

👌 Experiment pr-147834 created and queued.
🤖 Automatically detected try build f77b5bc
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

WaffleLapkin · 2025-10-26T21:11:03Z

When we stabilize the never type do we intend to change how NeverToAny coercions work? Will we continue unconditionally coercing ! to an inference variable, or will we stop doing that? Or in other words, is the stable behaviour here the behaviour we'd expect to have once never type is stabilized?

I don't expect / haven't heard of any desire to make any changes with how we insert NeverToAny coercions.

Always make tuple elements a coercion site Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example: ```rust ((),) = (loop {},); ``` With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile. Fixesrust-lang#112856 r? BoxyUwU

JonathanBrouwer · 2026-03-09T16:56:58Z

@bors yield
Yielding to enclosing rollup

rust-bors · 2026-03-09T16:57:01Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/22864686275

The next pull request likely to be tested is #153617.

…uwer Rollup of 4 pull requests Successful merges: - #147834 (Always make tuple elements a coercion site) - #150446 (miri/const eval: support `MaybeDangling`) - #153053 (stop marking `deref_patterns` as an incomplete feature) - #153398 (fix ICE in `const_c_variadic` when passing ZSTs)

rust-bors · 2026-03-09T17:02:11Z

⌛ Testing commit 3398ea2 with merge 82e4d00...

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

Always make tuple elements a coercion site Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example: ```rust ((),) = (loop {},); ``` With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile. Fixes#112856 r? BoxyUwU

JonathanBrouwer · 2026-03-09T17:03:15Z

@bors yield
Yielding to enclosing rollup

rust-bors · 2026-03-09T17:03:20Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/22865035946

The next pull request likely to be tested is #153617.

…uwer Rollup of 4 pull requests Successful merges: - #147834 (Always make tuple elements a coercion site) - #150446 (miri/const eval: support `MaybeDangling`) - #153053 (stop marking `deref_patterns` as an incomplete feature) - #153398 (fix ICE in `const_c_variadic` when passing ZSTs)

Rollup merge of #147834 - WaffleLapkin:tuple-coerce, r=BoxyUwU Always make tuple elements a coercion site Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example: ```rust ((),) = (loop {},); ``` With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile. Fixes#112856 r? BoxyUwU

…uwer Rollup of 4 pull requests Successful merges: - rust-lang/rust#147834 (Always make tuple elements a coercion site) - rust-lang/rust#150446 (miri/const eval: support `MaybeDangling`) - rust-lang/rust#153053 (stop marking `deref_patterns` as an incomplete feature) - rust-lang/rust#153398 (fix ICE in `const_c_variadic` when passing ZSTs)

…-never-coercion, r=jieyouxu Add tuple never coercion collection regression test Fixesrust-lang#100727 It's fixed by PR rust-lang#147834

Rollup merge of #159810 - chenyukang:yukang-fix-100727-tuple-never-coercion, r=jieyouxu Add tuple never coercion collection regression test Fixes#100727 It's fixed by PR #147834

…ercion, r=jieyouxu Add tuple never coercion collection regression test Fixesrust-lang/rust#100727 It's fixed by PR rust-lang/rust#147834

rustbot assigned BoxyUwU Oct 17, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 17, 2025

rustbot mentioned this pull request Oct 17, 2025
Tracking issue for release notes of #147834: Always make tuple elements a coercion site #147835
Closed

BoxyUwU reviewed Oct 25, 2025
View reviewed changes

BoxyUwU added needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 25, 2025

This comment has been minimized.
Sign in to view

rust-borsBot added a commit that referenced this pull request Oct 25, 2025
Auto merge of#147834- WaffleLapkin:tuple-coerce, r=<try>
f77b5bc
Always make tuple elements a coercion site

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 25, 2025

BoxyUwU added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 25, 2025

This comment has been minimized.
Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Oct 25, 2025

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 25, 2025

JonathanBrouwer mentioned this pull request Mar 9, 2026
Rollup of 4 pull requests #153617
Merged

rust-borsBot merged commit 3f1ddd5 into rust-lang:mainMar 9, 2026
11 of 12 checks passed

rustbot added this to the 1.96.0 milestone Mar 9, 2026

rust-rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting labels Mar 10, 2026

apiraino removed the to-announce Announce this issue on triage meeting label Apr 2, 2026

BoxyUwU mentioned this pull request May 12, 2026
Draft release notes for 1.96.0 #156512
Closed

chenyukang mentioned this pull request Jul 24, 2026
Add tuple never coercion collection regression test #159810
Merged

rust-timer added a commit that referenced this pull request Jul 27, 2026
Unrolled build for#159810
3660995
Rollup merge of #159810 - chenyukang:yukang-fix-100727-tuple-never-coercion, r=jieyouxu Add tuple never coercion collection regression test Fixes#100727 It's fixed by PR #147834

	pubfntuple(self) -> Option<&'tcxList<Ty<'tcx>>>{
	pubfnopt_tuple_fields(self) -> Option<&'tcxList<Ty<'tcx>>>{

Uh oh!

Uh oh!

Conversation

WaffleLapkin commented Oct 17, 2025• edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WaffleLapkinOct 26, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

BoxyUwU commented Oct 25, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

BoxyUwU commented Oct 25, 2025

Uh oh!

rust-borsBot commented Oct 25, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Oct 25, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

BoxyUwU commented Oct 25, 2025

Uh oh!

craterbot commented Oct 25, 2025

Uh oh!

WaffleLapkin commented Oct 26, 2025

Uh oh!

JonathanBrouwer commented Mar 9, 2026

Uh oh!

rust-borsBot commented Mar 9, 2026

Uh oh!

rust-borsBot commented Mar 9, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JonathanBrouwer commented Mar 9, 2026

Uh oh!

rust-borsBot commented Mar 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

WaffleLapkin commented Oct 17, 2025•
edited by rustbot
Loading

WaffleLapkinOct 26, 2025•
edited
Loading

rust-borsBot commented Mar 9, 2026•
edited
Loading