fix(needless_return_with_question_mark): skip when removing return ca…

[durationextender]

changelog: [needless_return_with_question_mark]: don't lint when removing the return would cause a partial move error

When the return is inside an if let that partially moves the scrutinee, and the scrutinee is used after the block, removing return breaks the borrow checker. This skips the lint in that case.
fixes #17421

[rustbot]

Thanks for the pull request. A reviewer will take a look after it receives 2 community reviews.

In the meantime, we would highly appreciate if you could try to review any of PRs waiting on community reviews.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[durationextender]

@rustbot ready

[Gri-ffin]

It's not mainly about the scrutinee being inside an if let block, or the scrutinee being used after that, it's about borrow/move semantics as the borrow checker can consider later code reachable (the return makes the divergence explicit), for example this would also fail:

#![allow(clippy::single_match)]

fn main() -> Result<(), String> {
    let v: Result<(), String> = Err("foo".to_string());

    match v {
        _whole @ Err(_) => {
            Err("bar".to_string())?;
        }
        Ok(_) => {}
    }

    let _ = v.unwrap();

    Ok(())
}

but if I add a ref, the code compiles perfectly fine, but from reading your fix, I believe that would be supressed although valid.

You should also fix dogfood errors.
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[ratmice]

@Gri-ffin In #17421 I mentioned that we couldn't add a ref to work around this because we we're calling a trait function on that owned value which was only implemented for the owned type (didn't implement Clone). We ended up moving the entire rest of the function into a match statement, but it was 200+ line change.

[Gri-ffin]

@Gri-ffin In #17421 I mentioned that we couldn't add a ref to work around this because we we're calling a trait function on...

I understand, I was just explaining the main issue and the problem with the current fix, and about the ref its more of an illustration to my point to the example I gave, since the current fix doesn't solve the main issue and introduce false negatives.

[rustbot]

☔ The latest upstream changes (possibly #17369) made this pull request unmergeable. Please resolve the merge conflicts.