Fix `if_then_some_else_none` FP when encountering `await` codes

[relaxcn]

changelog: Fix FP of [if_then_some_else_none] when the then block contains await codes.

That is because bool:then doesn't work with await code.

Closes: rust-lang/rust-clippy#16176

[rustbot]

r? @Jarcho

rustbot has assigned @Jarcho. 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

[rustbot]

:warning: Warning :warning:

• There are issue links (such as #123) in the commit messages of the following commits. Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 8f647399140e3c7fe9bd94f612cd89ef83638c4e

[github-actions[bot]]

No changes for 6159c1971fba705963377f1a90824f0269fa8682

[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.

[ada4a]

The new FP in manual_map is only partially related to these changes:

• It looks like can_move_expr_to_closure fails to notice the use of input inside trace!, most likely because the latter expands to nothing, and thus wrongly returns true.
• But in theory, manual_map should've avoided linting by itself, as it shouldn't lint then-block which contains statements (in this case, the trace!), but doesn't, as it doesn't notice trace!, as it expands to nothing.

Opened a separate issue for the latter: #16193

[relaxcn]

The new FP in manual_map is only partially related to these changes:

• It looks like can_move_expr_to_closure fails to notice the use of input inside trace!, most likely because the latter expands to nothing, and thus wrongly returns true.
• But in theory, manual_map should've avoided linting by itself, as it shouldn't lint then-block which contains statements (in this case, the trace!), but doesn't, as it doesn't notice trace!, as it expands to nothing.

Opened a separate issue for the latter: #16193

Yes. The new issue #16193 seems to be caused by can_move_expr_to_closure returns true wrongly.

Even though the manual_map could prevent it in the early age, I prefer to improve can_move_expr_to_closure to keep the lint code simple.

[Jarcho]

The change to can_partially_move_ty is causing the new FPs in option_if_let_else. Those will have to be fixed before this can be merged. manual_map has a partial workaround for the lack of lifetime checking that should be enough.

[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.

[relaxcn]

The change to can_partially_move_ty is causing the new FPs in option_if_let_else. Those will have to be fixed before this can be merged. manual_map has a partial workaround for the lack of lifetime checking that should be enough.

Agree. I've made minimal changes this time.