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

compiler/rustc_middle/src/ty/sty.rs


+    /// 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

pub fn tuple(self) -> Option<&'tcx List<Ty<'tcx>>> {

pub fn opt_tuple_fields(self) -> Option<&'tcx List<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

tests/ui/tuple/coercion.rs

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.

rustbot · 2026-03-09T11:21:17Z

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.

WaffleLapkin · 2026-03-09T15:18:09Z

@bors r=BoxyUwU

rust-bors · 2026-03-09T15:18:12Z

📋 This PR cannot be approved because it currently has the following labels: final-comment-period, S-waiting-on-fcp.

WaffleLapkin · 2026-03-09T15:19:45Z

@bors r=BoxyUwU

The FCP was blocked for a while, everyone had enough time to raise concerns. Agreed with boxy that this doesn't have to wait any longer.

rust-bors · 2026-03-09T15:19:50Z

📌 Commit 3398ea2 has been approved by BoxyUwU

It is now in the queue for this repository.

rust-bors · 2026-03-09T16:54:06Z

⌛ Testing commit 3398ea2 with merge a138e0d...

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

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

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 rust-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)

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

Open

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

always make tuple elements a coercion site

3398ea2

WaffleLapkin force-pushed the tuple-coerce branch from 8fd56a2 to 3398ea2 Compare March 9, 2026 11:21

WaffleLapkin removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. labels Mar 9, 2026

rust-bors bot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 9, 2026

JonathanBrouwer mentioned this pull request Mar 9, 2026

Rollup of 4 pull requests #153617

Merged

rust-bors bot merged commit 3f1ddd5 into rust-lang:main Mar 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

	pub fn tuple(self) -> Option<&'tcx List<Ty<'tcx>>> {
	pub fn opt_tuple_fields(self) -> Option<&'tcx List<Ty<'tcx>>> {

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!

WaffleLapkin Oct 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-bors bot 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!

rustbot commented Mar 9, 2026

Uh oh!

WaffleLapkin commented Mar 9, 2026

Uh oh!

rust-bors bot commented Mar 9, 2026

Uh oh!

WaffleLapkin commented Mar 9, 2026

Uh oh!

rust-bors bot commented Mar 9, 2026

Uh oh!

rust-bors bot 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-bors bot commented Mar 9, 2026

Uh oh!

rust-bors bot 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-bors bot commented Mar 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

WaffleLapkin commented Oct 17, 2025 •

edited by rustbot

Loading

WaffleLapkin Oct 26, 2025 •

edited

Loading

rust-bors bot commented Mar 9, 2026 •

edited

Loading

rust-bors bot commented Mar 9, 2026 •

edited

Loading