Skip to content

Conversation

nahuakang
Copy link
Contributor

@nahuakang nahuakang commented Feb 7, 2021

This WIP PR is an attempt to refactor files with many lints into a more accessible structure.

Notes:

  • All lint definitions, declare_clippy_lint! for lints and impl LintPass will reside in the loops/mod.rs.
  • Lint functions will reside in their corresponding files.
  • Utility functions of the loops module will be moved into loops/utils.rs and then reexported for the module in mod.rs.

This way, loops.rs will be re-arrange into the following structure under clippy_lints/src:

loops
├── manual_flatten.rs
├── mod.rs
├── ...other lints...
└── utils.rs
  • Followed [lint naming conventions][lint_naming]
  • Added passing UI tests (including committed .stderr file)
  • cargo test passes locally
  • Executed cargo dev update_lints
  • Added lint documentation
  • Run cargo dev fmt

Please write a short comment explaining your change (or "none" for internal only changes)
changelog:
Refactor loops.rs file into loops module.

@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 Feb 7, 2021
@nahuakang nahuakang changed the title (WIP) Refactor: organize loops file into loops module Refactor: organize loops file into loops module Feb 9, 2021
@nahuakang nahuakang marked this pull request as ready for review February 9, 2021 22:29
@nahuakang
Copy link
Contributor Author

r? @flip1995

@rust-highfive rust-highfive assigned flip1995 and unassigned phansch Feb 9, 2021
@bors
Copy link
Contributor

bors commented Feb 10, 2021

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

Copy link
Contributor

@Y-Nak Y-Nak left a comment

Choose a reason for hiding this comment

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

About styles.

@Y-Nak Y-Nak mentioned this pull request Feb 16, 2021
@flip1995 flip1995 added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Feb 21, 2021
@flip1995
Copy link
Member

@Y-Nak @nahuakang @magurotuna Thanks for your work and cross reviews. I'll do a final check of your PRs once this PR is ready. 👍

@nahuakang
Copy link
Contributor Author

@Y-Nak @magurotuna @flip1995 Thanks for all the feedback. I've incorporated your comments as much as I can. This branch has also been updated with rust-lang:master and reflects the most recent changes to the loops.rs file from #6698. Let me know what you think!

@nahuakang nahuakang requested a review from flip1995 February 21, 2021 18:42
@Y-Nak
Copy link
Contributor

Y-Nak commented Feb 22, 2021

Could you use rebase instead of merge to resolve conflicts because we follow a rustc no merge-commit policy? See this for more details.

@bors
Copy link
Contributor

bors commented Feb 25, 2021

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

Copy link
Contributor

@magurotuna magurotuna left a comment

Choose a reason for hiding this comment

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

LGTM 👍 (except for the conflict)

use rustc_hir::{Block, Expr};
use rustc_lint::LateContext;

pub(super) fn check_empty_loop(cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>, loop_block: &'tcx Block<'_>) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it would be great to unify the name of the main entry functions of all modules to check.

Comment on lines +612 to +614
if is_ref_iterable_type(cx, &args[0]) {
explicit_iter_loop::lint_iter_method(cx, args, arg, method_name);
}
Copy link
Contributor

@Y-Nak Y-Nak Feb 25, 2021

Choose a reason for hiding this comment

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

I think check_for_loop_arg should only decide which function to be called according to the method name. The current implementation of check_for_loop_arg seems to do too many works.
And is_ref_iterable_type should be called inside lint_iter_method because it's a quite detailed implementation of explicit_iter_loop.

Suggested change
if is_ref_iterable_type(cx, &args[0]) {
explicit_iter_loop::lint_iter_method(cx, args, arg, method_name);
}
explicit_iter_loop::lint_iter_method(cx, args, arg, method_name);

Comment on lines +616 to +630
let receiver_ty = cx.typeck_results().expr_ty(&args[0]);
let receiver_ty_adjusted = cx.typeck_results().expr_ty_adjusted(&args[0]);
if TyS::same_type(receiver_ty, receiver_ty_adjusted) {
explicit_into_iter_loop::check_explicit_into_iter_loop(cx, args, arg);
} else {
let ref_receiver_ty = cx.tcx.mk_ref(
cx.tcx.lifetimes.re_erased,
ty::TypeAndMut {
ty: receiver_ty,
mutbl: Mutability::Not,
},
);
if TyS::same_type(receiver_ty_adjusted, ref_receiver_ty) {
explicit_iter_loop::lint_iter_method(cx, args, arg, method_name)
}
Copy link
Contributor

@Y-Nak Y-Nak Feb 25, 2021

Choose a reason for hiding this comment

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

ditto.
The implemetation of methods/mod.rs would be great help to grab the idea.

Suggested change
let receiver_ty = cx.typeck_results().expr_ty(&args[0]);
let receiver_ty_adjusted = cx.typeck_results().expr_ty_adjusted(&args[0]);
if TyS::same_type(receiver_ty, receiver_ty_adjusted) {
explicit_into_iter_loop::check_explicit_into_iter_loop(cx, args, arg);
} else {
let ref_receiver_ty = cx.tcx.mk_ref(
cx.tcx.lifetimes.re_erased,
ty::TypeAndMut {
ty: receiver_ty,
mutbl: Mutability::Not,
},
);
if TyS::same_type(receiver_ty_adjusted, ref_receiver_ty) {
explicit_iter_loop::lint_iter_method(cx, args, arg, method_name)
}
explicit_into_iter_loop::check_explicit_into_iter_loop(cx, args, arg);
explicit_iter_loop::lint_iter_method(cx, args, arg, method_name);

@nahuakang
Copy link
Contributor Author

Thanks a lot for the additional comments, @Y-Nak. I'm unfortunately on sick leave and will not work for the next 3-4 days. If you have time until then, could you please help address the comments? Otherwise I'll address them after :) Cheers.

@flip1995
Copy link
Member

flip1995 commented Mar 2, 2021

Closing in favor of #6824

@flip1995 flip1995 closed this Mar 2, 2021
bors added a commit that referenced this pull request Mar 3, 2021
Refactor: organize loops file into loops module (Delegated)

`@flip1995` `@nahuakang`

closes #6693
r? `@flip1995`

 As we talked about in the PM of Zulip,  this PR is a delegated PR from `@nahuakang.`

Changes from the last commit of #6693:
1. Unify the name of the main entries of all modules to check, that was pointed out [here](#6693 (comment))
2. Simplify ` check_for_loop_arg`, that was pointed out [here](#6693 (comment)) and [here](#6693 (comment))
3. Resolve conflicts

changelog: Refactor `loops.rs` file into `loops` module.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants