-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Merge some lints together #5563
Conversation
Btw, i'm not sure about |
✔️
❌ →
✔️
✔️
❌ This is intentional, since the first one is a sylte lint and the second one is a restriction lint
✔️
✔️ And move it to restriction
❌ modulo_one is different from modulo_arithmetic (correctness vs restriction) also different intentions. I would also left cc @rust-lang/clippy |
Lint renamed.
Commit deleted, lint is back.
Done
No problem let's wait for feedback |
@flip1995's suggestions seem good, though i'm a bit wary of the string_add one. Also we should set these up as renamed lints so the old names still work and we have proper diagnostics. |
Oh I should have read the description of those lints more carefully. I thought one lints After reading it more carefully I would also keep them as separate lints. @ThibsG can you revert the commit for |
The |
☔ The latest upstream changes (presumably #5583) made this pull request unmergeable. Please resolve the merge conflicts. |
…ints into `block_in_if_condition` lint
…_map_unwrap_or_else` lints into `map_unwrap` lint
…or_loop_over_fallible` lint
Do I need to change something in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
singular -> plural for 2 lint names. Otherwise this LGTM.
In the CHANGELOG.md
you have to remove old links to the old names. The offending lines are as follows:
201:3-201:27
285:5-285:27
286:5-286:27
398:27-398:56
398:61-398:90
451:25-451:49
797:47-797:76
1071:3-1071:27
1071:32-1071:61
1090:33-1090:57
1091:3-1091:27
Just remove the []
around the lint names.
Sorry for not re-reviewing for so long, force pushes to PRs sometimes don't show up in the GH notifications.
Thanks! @bors r+ |
📌 Commit ab87f87 has been approved by |
@bors p=1 |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
This PR merges following lints:
block_in_if_condition_expr
andblock_in_if_condition_stmt
→blocks_in_if_conditions
option_map_unwrap_or
,option_map_unwrap_or_else
andresult_map_unwrap_or_else
→map_unwrap
option_unwrap_used
andresult_unwrap_used
→unwrap_used
option_expect_used
andresult_expect_used
→expect_used
wrong_pub_self_convention
intowrong_self_convention
for_loop_over_option
andfor_loop_over_result
→for_loops_over_fallibles
Lints that have already been merged since the issue was created:
new_without_default
andnew_without_default_derive
→new_without_default
Need more discussion:
string_add
andstring_add_assign
: do we agree to merge them or not? Is there something more to do? → not merge finallyidentity_op
andmodulo_one
→useless_arithmetic
: seems outdated, sincemodulo_arithmetic
has been created.fixes #1078
changelog: Merging some lints together:
block_in_if_condition_expr
andblock_in_if_condition_stmt
→blocks_in_if_conditions
option_map_unwrap_or
,option_map_unwrap_or_else
andresult_map_unwrap_or_else
→map_unwrap_or
option_unwrap_used
andresult_unwrap_used
→unwrap_used
option_expect_used
andresult_expect_used
→expect_used
for_loop_over_option
andfor_loop_over_result
→for_loops_over_fallibles