Skip to content

Don't lint blocks in closures for blocks_in_conditions #12805

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
Jun 8, 2024

Conversation

Alexendoo
Copy link
Member

Seemed like an outlier for the lint which generally caught only the syntactically confusing cases, it lints blocks in closures but excludes closures passed to iterator methods, this changes it to ignore closures in general

changelog: none

@rustbot
Copy link
Collaborator

rustbot commented May 15, 2024

r? @dswij

rustbot has assigned @dswij.
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 15, 2024
@y21
Copy link
Member

y21 commented May 15, 2024

I think this also basically (indirectly) fixes #12281 , right? Last time I looked into that issue it gets to the code that's deleted here because #[tracing::instrument] has match async move { ... } {} expansions that desugar to closures

@Alexendoo Alexendoo linked an issue May 16, 2024 that may be closed by this pull request
@Alexendoo
Copy link
Member Author

Yeah looks like it, there's also an extra context check for the main part of the lint that wasn't checked for the closure checking

@Alexendoo

This comment was marked as resolved.

@bors

This comment was marked as resolved.

bors added a commit that referenced this pull request May 16, 2024
Don't lint blocks in closures for blocks_in_conditions

Seemed like an outlier for the lint which generally caught only the syntactically confusing cases, it lints blocks in closures but excludes closures passed to iterator methods, this changes it to ignore closures in general

changelog: none
@bors

This comment was marked as resolved.

@rust-cloud-vms rust-cloud-vms bot force-pushed the blocks-in-conditions-closures branch from 2c8f91a to 7a49ad4 Compare June 2, 2024 18:47
@bors
Copy link
Contributor

bors commented Jun 7, 2024

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

@rust-cloud-vms rust-cloud-vms bot force-pushed the blocks-in-conditions-closures branch from 7a49ad4 to b21ee38 Compare June 7, 2024 11:28
Copy link
Member

@dswij dswij left a comment

Choose a reason for hiding this comment

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

Sweet, thanks!

@dswij
Copy link
Member

dswij commented Jun 8, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Jun 8, 2024

📌 Commit b21ee38 has been approved by dswij

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jun 8, 2024

⌛ Testing commit b21ee38 with merge 48686ad...

@bors
Copy link
Contributor

bors commented Jun 8, 2024

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: dswij
Pushing 48686ad to master...

@bors bors merged commit 48686ad into rust-lang:master Jun 8, 2024
5 checks passed
@Alexendoo Alexendoo deleted the blocks-in-conditions-closures branch June 8, 2024 13:29
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.

tracing::instrument triggers blocks_in_conditions
5 participants