Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

needless_return_with_question_mark ignore let-else #11802

Merged
merged 1 commit into from Nov 15, 2023

Conversation

dswij
Copy link
Member

@dswij dswij commented Nov 13, 2023

Fixes #11765

This PR makes needless_return_with_question_mark to ignore expr inside let-else.

changelog: [needless_return_with_question_mark] ignore let-else

@rustbot
Copy link
Collaborator

rustbot commented Nov 13, 2023

r? @xFrednet

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Nov 13, 2023
Comment on lines 441 to 449
fn is_let_else_block(tcx: TyCtxt<'_>, e: &Expr<'_>) -> bool {
for (_, node) in tcx.hir().parent_iter(e.hir_id) {
if let Node::Local(Local { els: Some(_), .. }) = node {
return true;
}
}

false
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty nit picky:

I feel like the if let Node::Local(Local { els: Some(_), .. }) check could be a bit too general, as it doesn't check, that the expression comes from the else branch:

fn x() -> Result<(), ()> {
    let Some(_): Option<()> = ({
        return Err(())?;
    }) else {
        panic!();
    };
}

Even if that's pretty weird code...

Could you try if this works:

fn is_let_else_block(tcx: TyCtxt<'_>, e: &Expr<'_>) -> bool {
    let mut child_id = e.hir_id;
    for (parent_id, node) in tcx.hir().parent_iter(e.hir_id) {
        if let Node::Local(Local { els: Some(els), .. }) = node
            && els.hir_id == child_id
        {
            return true;
        }
        child_id = parent_id;
    }

    false
}

Then we could probably move this into clippy_utils in case other lints need something like this :). If not, it's totally fine. I think this code is already good enough of a heuristic, to avoid FPs and r+ the PR :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 yeah fair enough, if we're going to move this to util, then this needs to be as precise as possible.

fn x() -> Result<(), ()> {
    let Some(_): Option<()> = ({
        return Err(())?;
    }) else {
        panic!();
    };
}

This is kind of outrageous for an FN of this lint, there's more to worry about than a needless return 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, just remembered that we'd need to ignore this as well

fn x() -> Result<(), ()> {
    let Some(_): Option<()> = ({
        return Err(())?;
    }) else {
        panic!();
    };
}

removing the return here leads to more complications than benefits; e.g. here it leads to compilation error, and if we have the same type, it might change the behavior.

Could you try if this works:

But this does work

@dswij dswij force-pushed the issue-11765 branch 3 times, most recently from b29b31b to eb72ebc Compare November 14, 2023 08:22
@xFrednet
Copy link
Member

LGTM, thank you for the update :)

@bors r+

@bors
Copy link
Collaborator

bors commented Nov 15, 2023

📌 Commit 48f38eb has been approved by xFrednet

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Nov 15, 2023

⌛ Testing commit 48f38eb with merge 7ad3373...

@bors
Copy link
Collaborator

bors commented Nov 15, 2023

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: xFrednet
Pushing 7ad3373 to master...

@bors bors merged commit 7ad3373 into rust-lang:master Nov 15, 2023
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect suggestion for needless_return_with_question_mark with let else
4 participants