Skip to content
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

Refactor: arrange lints in methods module #6826

Merged
merged 35 commits into from
Mar 11, 2021

Conversation

TaKO8Ki
Copy link
Member

@TaKO8Ki TaKO8Ki commented Mar 2, 2021

This PR arranges methods lints so that they can be accessed more easily.
Basically, I refactored them following the instruction described in #6680.

changelog: Move lints in methods module into their own modules.

@rust-highfive
Copy link

r? @phansch

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 2, 2021
@TaKO8Ki TaKO8Ki changed the title [WIP] Refactor: arrange methods lints [WIP] Refactor: arrange lints in methods mod Mar 2, 2021
Copy link
Member

@phansch phansch left a comment

Choose a reason for hiding this comment

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

I really like these refactors! Feel free to @ me again, when you're ready for a review =)

@TaKO8Ki
Copy link
Member Author

TaKO8Ki commented Mar 2, 2021

@phansch
Thank you! :)

@TaKO8Ki TaKO8Ki changed the title [WIP] Refactor: arrange lints in methods mod [WIP] Refactor: arrange lints in methods module Mar 2, 2021
@TaKO8Ki TaKO8Ki changed the title [WIP] Refactor: arrange lints in methods module [WIP] Refactor: arrange lints in methods module Mar 2, 2021
@camsteffen
Copy link
Contributor

You should probably split into a new PR every 10 or so lints for the reviewers' sanity 😄

@TaKO8Ki
Copy link
Member Author

TaKO8Ki commented Mar 11, 2021

@camsteffen
You’re right. I've already refactored most of lints in methods module. The others things to do is refactoring the rest of lints and moving some functions to clippy_lints/src/utils/methods/. I'm going to do them in a new PR!

@TaKO8Ki TaKO8Ki changed the title [WIP] Refactor: arrange lints in methods module Refactor: arrange lints in methods module Mar 11, 2021
@TaKO8Ki TaKO8Ki requested a review from phansch March 11, 2021 05:44
@TaKO8Ki
Copy link
Member Author

TaKO8Ki commented Mar 11, 2021

@phansch
I'm ready for your review! ref: comment above

@phansch
Copy link
Member

phansch commented Mar 11, 2021

@TaKO8Ki great! I will try to finish the review in the next 12 hours so that we don't run in too many conflicts with other PRs

}
}
}

fn fn_header_equals(expected: hir::FnHeader, actual: hir::FnHeader) -> bool {
Copy link
Member

Choose a reason for hiding this comment

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

If those utils functions are used in more than one lint, please move it to a methods/utils.rs module. If it is only used in one lint, move it to the lint module. If it is only used in mod.rs, just leave it here.

Copy link
Member

Choose a reason for hiding this comment

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

A quick search would suggest, that this function should stay in mod.rs, but e.g. derefs_to_slice is used in multiple lint files and should therefore be moved to methods/utils.rs

Copy link
Member Author

Choose a reason for hiding this comment

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

You're right. I think I should move some functions such as derefs_to_slice to methods/utils.rs, however this PR is too big. So, I'm going to fix this in a new PR. ref comment above

Comment on lines 1781 to 1810
let self_ty = cx.typeck_results().expr_ty_adjusted(&args[0]);
if args.len() == 1 && method_call.ident.name == sym::clone {
lint_clone_on_copy(cx, expr, &args[0], self_ty);
lint_clone_on_ref_ptr(cx, expr, &args[0]);
clone_on_copy::check(cx, expr, &args[0], self_ty);
clone_on_ref_ptr::check(cx, expr, &args[0]);
}
if args.len() == 1 && method_call.ident.name == sym!(to_string) {
inefficient_to_string::lint(cx, expr, &args[0], self_ty);
inefficient_to_string::check(cx, expr, &args[0], self_ty);
}

if let Some(fn_def_id) = cx.typeck_results().type_dependent_def_id(expr.hir_id) {
if match_def_path(cx, fn_def_id, &paths::PUSH_STR) {
lint_single_char_push_string(cx, expr, args);
single_char_push_string::check(cx, expr, args);
} else if match_def_path(cx, fn_def_id, &paths::INSERT_STR) {
lint_single_char_insert_string(cx, expr, args);
single_char_insert_string::check(cx, expr, args);
}
}

match self_ty.kind() {
ty::Ref(_, ty, _) if *ty.kind() == ty::Str => {
for &(method, pos) in &PATTERN_METHODS {
if method_call.ident.name.as_str() == method && args.len() > pos {
lint_single_char_pattern(cx, expr, &args[pos]);
single_char_pattern::check(cx, expr, &args[pos]);
}
}
},
ty::Ref(..) if method_call.ident.name == sym::into_iter => {
lint_into_iter(cx, expr, self_ty, *method_span);
into_iter_on_ref::check(cx, expr, self_ty, *method_span);
},
_ => (),
}
Copy link
Contributor

Choose a reason for hiding this comment

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

These lines seem to do too many tasks.
I think checks that decide whether the lint is triggered should be moved to each module if duplications are not so much.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you for your suggestions! I think so too. However, this PR is too big and I have to commit many changes in order to move them to each module. So I'm going to do it in a new PR 👍 ref: #6826 (comment)

@bors
Copy link
Collaborator

bors commented Mar 11, 2021

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

@TaKO8Ki
Copy link
Member Author

TaKO8Ki commented Mar 11, 2021

for all reviewers

This PR is too big. So, if your suggestions are big, I'm going to accept them in a new PR. ref #6826 (comment)

@flip1995
Copy link
Member

@TaKO8Ki sounds good to me! (And sorry for the merge conflict (-.-) )

@phansch
Copy link
Member

phansch commented Mar 11, 2021

I agree that we should keep further improvements out of this PR 👍

@Y-Nak
Copy link
Contributor

Y-Nak commented Mar 11, 2021

I agree that too.

@TaKO8Ki
Copy link
Member Author

TaKO8Ki commented Mar 11, 2021

@flip1995 @phansch @Y-Nak
I finished resolving conflicts!

@TaKO8Ki TaKO8Ki requested a review from flip1995 March 11, 2021 11:30
@Y-Nak
Copy link
Contributor

Y-Nak commented Mar 11, 2021

@TaKO8Ki Could you summarize the future works and reviews you received here in #6680 or a new issue?
It really helps us to track them easily.

@TaKO8Ki
Copy link
Member Author

TaKO8Ki commented Mar 11, 2021

@Y-Nak
I opened a tracking issue #6886.

Copy link
Member

@phansch phansch left a comment

Choose a reason for hiding this comment

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

Left some comments unrelated to this refactoring that can be fixed in later PRs

pub(super) fn check<'tcx>(
cx: &LateContext<'tcx>,
expr: &'tcx hir::Expr<'_>,
_filter_args: &'tcx [hir::Expr<'_>],
Copy link
Member

Choose a reason for hiding this comment

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

We should review all new functions for unused arguments

Comment on lines +47 to +51
} else if is_type_diagnostic_item(cx, cx.typeck_results().expr_ty(caller_expr), sym::vec_type)
|| matches!(
&cx.typeck_results().expr_ty(caller_expr).peel_refs().kind(),
ty::Array(_, _)
)
Copy link
Member

Choose a reason for hiding this comment

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

This condition (not the body) could probably be extracted into its own function

// lint if caller of skip is an Iterator
if match_trait_method(cx, expr, &paths::ITERATOR) {
if let [caller, n] = skip_args {
let hint = format!(".nth({})", snippet(cx, n.span, ".."));
Copy link
Member

Choose a reason for hiding this comment

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

No need to have this as a separate variable

}

/// This checks whether a given type is known to implement Debug.
fn has_debug_impl<'tcx>(ty: Ty<'tcx>, cx: &LateContext<'tcx>) -> bool {
Copy link
Member

Choose a reason for hiding this comment

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

Might be worth moving to utils


pub(super) fn check(cx: &LateContext<'_>, expr: &hir::Expr<'_>, args: &[hir::Expr<'_>]) {
let obj_ty = cx.typeck_results().expr_ty(&args[0]).peel_refs();
if is_type_diagnostic_item(cx, obj_ty, sym::string_type) {
Copy link
Member

Choose a reason for hiding this comment

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

Returning early here or using if_chain would reduce some indentation in a lot of lints, like here.

@phansch
Copy link
Member

phansch commented Mar 11, 2021

@bors r+ This is a huge step forward, thanks!

@bors
Copy link
Collaborator

bors commented Mar 11, 2021

📌 Commit 83a9553 has been approved by phansch

@bors
Copy link
Collaborator

bors commented Mar 11, 2021

⌛ Testing commit 83a9553 with merge 6ed6f1e...

@bors
Copy link
Collaborator

bors commented Mar 11, 2021

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: phansch
Pushing 6ed6f1e to master...

@bors bors merged commit 6ed6f1e into rust-lang:master Mar 11, 2021
@TaKO8Ki TaKO8Ki deleted the refactor-methods-mod branch March 12, 2021 02:49
bors added a commit that referenced this pull request Mar 22, 2021
…nsch

Refactor lints in methods module

This PR refactors methods lints other than the lints I refactored in #6826 and moves some functions to methods/utils.rs.
Basically, I follow the instruction described in #6680.

**For ease of review, I refactored step by step, keeping each commit small.**

closes #6886
cc: `@phansch,` `@flip1995,` `@Y-Nak`

changelog: Move lints in methods module to their own modules and some function to methods/utils.rs.
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.

7 participants