Avoid invalid if_then_some_else_none suggestions in try blocks

[eviaaaaa]

When if_then_some_else_none rewrites an if expression to bool::then, it moves the Some branch into a new closure. A ? whose residual break targets an enclosing try block cannot move into that closure: the generated code instead tries to use ? from a closure returning the inner value, and fails to compile.

The previous guard handled explicit return and yield, but a ? inside a try block lowers to MatchSource::TryDesugar with a residual Break, so the lint still emitted a machine-applicable suggestion.

This change inspects that residual break destination. The lint is suppressed only when the destination is outside the expression being moved. A nested try { ... } moves together with the Some branch, so its ? remains valid and the suggestion is still emitted.

fixes #17596

The regression matrix was run against the unmodified lint first: direct and statement-form ? cases produced unexpected diagnostics, and compiling the exact suggestion failed with E0277 because the new closure did not return Result, Option, or another FromResidual type.

The UI coverage includes:

• direct and statement-form ? targeting the enclosing try block;
• single and multiple nested try blocks whose targets move with the expression;
• a nested closure and a branch without ? as positive controls;
• rustfix output that compiles for the still-valid suggestions.

UI/rustfix coverage was added for both enclosing and nested try contexts; the relevant UI tests and clippy_lints test suite pass.

changelog: [if_then_some_else_none]: avoid suggestions that move ? out of its enclosing try context

[rustbot]

Thanks for the pull request, and welcome!

You should hear from one of our reviewers after this PR gets at least 2 reviews from the community.

Please see the contribution instructions for more information.

[CommanderStorm]

community review:
actual code LGTM, but I have two minor asks to improve the code while we are at it 😉

View changes since this review

[eviaaaaa]

@CommanderStorm Thanks for the review. I addressed all four points in 6631233, and CI is green. Could you take another look when you have a chance?

Extracted the nested logic into is_invalid_try_break. I used HirId for the second parameter to match the suggested call and keep the helper limited to the data it needs.

[CommanderStorm]

Community review: LGTM, thanks for the changes

View changes since this review

[CommanderStorm]

make sure to squash them into one commit 😉