Always make tuple elements a coercion site

[WaffleLapkin]

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]

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

[BoxyUwU]

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

[WaffleLapkin]

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.

[BoxyUwU]

can you split the failing cases out to a different test so that the working stuff can be marked // @check-pass . It's also nice because this change probably needs an FCP because we start allowing more code to compile so having a simple "this is the test that now passes" is nice

[WaffleLapkin]

I've split the tests

[BoxyUwU]

@bors try @rust-timer queue

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

[BoxyUwU]

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]

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

[rust-timer]

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]

@craterbot check

[craterbot]

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

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]

This PR was rebased onto a different master 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.

[craterbot]

🚧 Experiment pr-147834 is now running

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