Skip to content

Fix unnecessary_unwrap emitted twice in closure (#14763) #14770

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

Merged
merged 1 commit into from
May 10, 2025

Conversation

relaxcn
Copy link
Contributor

@relaxcn relaxcn commented May 9, 2025

The problem is that check_fn is triggered by both function and closure, and visit_expr can visit expressions in another closures within a function or closure.

So just skip walking in a inner closure.

changelog: Fix [unnecessary_unwrap] emitted twice in closure which inside in a function or another closure.

Fixes: #14763

@rustbot
Copy link
Collaborator

rustbot commented May 9, 2025

r? @samueltardieu

rustbot has assigned @samueltardieu.
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 rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label May 9, 2025
Copy link
Contributor

@samueltardieu samueltardieu left a comment

Choose a reason for hiding this comment

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

LGTM, except for a minor comment fix to explain why we don't recurse into closures

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels May 9, 2025
Copy link
Contributor

@samueltardieu samueltardieu left a comment

Choose a reason for hiding this comment

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

Can you please squash the commits together? Then it will be ready to be merged.

@relaxcn
Copy link
Contributor Author

relaxcn commented May 9, 2025

Sure.

@relaxcn
Copy link
Contributor Author

relaxcn commented May 9, 2025

I have a question.

Why using Unwrap::check_fn() instead of check_fn() in your comment?

@samueltardieu
Copy link
Contributor

I have a question.

Why using Unwrap::check_fn() instead of check_fn() in your comment?

No particular reason, except that since check_fn() is not part of the Visitor trait but belongs to the LateLintPass one I thought it was clearer to fully qualify it.

You prefer to use the short form?

@relaxcn
Copy link
Contributor Author

relaxcn commented May 10, 2025

No, your change looks good for me.

Because I'm new, so I just have some doubts.

Thanks for your reply.

You can merge it now.😊

@samueltardieu samueltardieu enabled auto-merge May 10, 2025 08:16
@relaxcn relaxcn requested a review from samueltardieu May 10, 2025 12:35
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels May 10, 2025
@relaxcn
Copy link
Contributor Author

relaxcn commented May 10, 2025

Sory, I just want to make sure what else do I need to do now?

It seems that you need to accept the changes firstly.

@samueltardieu samueltardieu added this pull request to the merge queue May 10, 2025
Merged via the queue into rust-lang:master with commit 5262ab2 May 10, 2025
11 checks passed
@relaxcn relaxcn deleted the fix-14763 branch May 30, 2025 08:30
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.

unnecessary_unwrap emitted twice in closure
3 participants