rustc_trait_selection: adopt let else in more places

[est31]

Continuation of #89933, #91018, #91481, #93046, #93590, #94011.

I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This PR handles rustc_trait_selection.

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[jackh726]

I'm not exactly sure what it is, but a lot of these just...give me a weird feeling. Like, with a match, your choices are "together" - you can see that e.g. in the Some case you do one thing, and the None case you do another. But when you replace with let else, your Some case is far (depending on how the expression is formatted) from the else case. It honestly screams for like a cross control-flow boundary return, so you could do .unwrap_or_else(|| return@outer) (taking some inspiration from Kotlin). Even moving the return to the same line wouldn't be bad ... else return; (I know this was brought up in the RFC)

I guess I probably don't object to anything in particular here, but I'd like to hear your thoughts. This also is maybe something to bring up in the stabilization discussion.

[est31]

Thanks for your input. I think it's the intent to format else { return }; on one line if possible once rustfmt supports let else: rust-lang/style-team#165 . I haven't done it in this PR particular because it felt to me that the lines would be quite long already, but i did it in other PRs of this series. It is true that match puts the options "together". unwrap_or_else is not as flexible as let else is as the latter supports arbitrary refutable patterns, the former only a bunch of types it's implemented on.

[Mark-Simulacrum]

Opening all of these together has spread the discussion out a little, but I think my feelings in #94146 (comment) largely echo those of @jackh726 here -- blanket application of let-else feels like it sometimes detracts more than it adds.

[cjgillot]

@bors r+

[bors]

📌 Commit dab5c44 has been approved by cjgillot

[bors]

⌛ Testing commit dab5c44 with merge 9323028...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 9323028 to master...

[rust-timer]

Finished benchmarking commit (9323028): comparison url.

Summary: This benchmark run did not return any relevant results. 1 results were found to be statistically significant but too small to be relevant.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression