Skip to content

Check for try blocks in question_mark more consistently #12341

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 2 commits into from
Mar 4, 2024

Conversation

y21
Copy link
Member

@y21 y21 commented Feb 23, 2024

Fixes #12337

I split this PR up into two commits since this moves a method out of an impl, which makes for a pretty bad diff (the &self parameter is now unused, and there isn't a reason for that function to be part of the impl now).

The first commit is the actual relevant change and the 2nd commit just moves stuff (github's "hide whitespace" makes the diff easier to look at)


Now for the actual issue:

? within try {} blocks desugars to a break to the block, rather than a return, so that changes behavior in those cases.

The lint has multiple patterns to look for and in some of them it already does correctly check whether we're in a try block, but this isn't done for all of its patterns.

We could add another self.inside_try_block() check to the function that looks for let-else-return, but I chose to actually just move those checks out and instead have them in LintPass::check_{stmt,expr}. This has the advantage that we can't (easily) accidentally forget to add that check in new patterns that might be added in the future.

(There's also a bit of a subtle interaction between two lints, where question_mark's LintPass calls into manual_let_else, so I added a check to make sure we don't avoid linting for something that doesn't have anything to do with ?)

changelog: [question_mark]: avoid linting on try blocks in more cases

@rustbot
Copy link
Collaborator

rustbot commented Feb 23, 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 Feb 23, 2024
@bors
Copy link
Contributor

bors commented Feb 25, 2024

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

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.

Thanks! As always, can you help to solve the conflict here by rebasing? Then it's good to go

@y21
Copy link
Member Author

y21 commented Mar 4, 2024

(Rebased.)

@dswij
Copy link
Member

dswij commented Mar 4, 2024

Thank you! @bors r+

@bors
Copy link
Contributor

bors commented Mar 4, 2024

📌 Commit 1430623 has been approved by dswij

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Mar 4, 2024

⌛ Testing commit 1430623 with merge e970fa5...

@bors
Copy link
Contributor

bors commented Mar 4, 2024

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

@bors bors merged commit e970fa5 into rust-lang:master Mar 4, 2024
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.

? error propagation lint breaks with try-blocks
4 participants