Properly check that an expression might be the one returned

[samueltardieu]

The TyCtxt::hir_get_fn_id_for_return_block() function was too broad, as it will return positively even when given part of an expression that can be used as a return value. A new potential_return_of_enclosing_body() utility function has been made to represent the fact that an expression might be directly returned from its enclosing body.

changelog: [return_and_then]: prevent false positives in case of a partially used expression

Fixes #15111
Fixes #14927

Summary Notes

• Beta-nomination by samueltardieu

Managed by @rustbot—see help for details

[rustbot]

r? @llogiq

rustbot has assigned @llogiq.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[samueltardieu]

@rustbot label +beta-nominated.
@rustbot note Beta-nomination

The issue is beta-nominated because the extension of scope which causes the issue was introduced in #14783 which will be part of Rust 1.89.

[y21]

I assume this also fixes #14927, right? I also commented in #14950 (comment) (PR that fixes the same issue) that it seemed odd to me that we're even processing expressions in these positions and that hir_get_fn_id_for_return_block should've filtered it out given the method name (or if it doesn't, we're probably misusing that function and should fix that part instead). So +1 for this approach

[samueltardieu]

I had missed #14927, this fixes it indeed, and I've added the test case.

I was going to first investigate fixing hir_get_fn_id_for_return_block() in r-l/r, but I didn't want to wait for integration+next sync given that the issue has entered the beta branch. I've added this to my todo list though.