mirror of
https://github.com/rust-lang/rust-clippy
synced 2025-02-17 14:38:46 +00:00
e970fa52e7
Check for try blocks in `question_mark` more consistently 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 |
||
|---|---|---|
| .. | ||
| test_utils | ||
| ui | ||
| ui-cargo | ||
| ui-internal | ||
| ui-toml | ||
| workspace_test | ||
| check-fmt.rs | ||
| clippy.toml | ||
| compile-test.rs | ||
| dogfood.rs | ||
| headers.rs | ||
| integration.rs | ||
| lint_message_convention.rs | ||
| missing-test-files.rs | ||
| versioncheck.rs | ||
| workspace.rs | ||