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

Add new lint iter_not_returning_iterator #7610

Merged
merged 1 commit into from
Sep 9, 2021
Merged

Add new lint iter_not_returning_iterator #7610

merged 1 commit into from
Sep 9, 2021

Conversation

Labelray
Copy link
Contributor

@Labelray Labelray commented Aug 31, 2021

Add new lint [iter_not_returning_iterator] to detect method iter() or iter_mut() returning a type not implementing Iterator
changelog: Add new lint [iter_not_returning_iterator]

@rust-highfive
Copy link

r? @camsteffen

(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 Aug 31, 2021
Comment on lines 94 to 97
let parameters = fn_sig.decl.inputs;
if parameters.is_empty() || parameters.len() > 1 {
return;
}

Choose a reason for hiding this comment

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

Why check for number of parameters?
Shouldn't this lint work for an iter that takes parameters other than self?
Or maybe this is covered by another lint?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it should only detect fn iter(&self) -> _ before, because I think if it has more parameters it may have a different meaning, so this lint may not suit it.

Copy link
Contributor

Choose a reason for hiding this comment

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

You can use if let [param] = fn_sig.decl.inputs. The if_chains can be collapsed. Can you also check that the parameter is &self?

if parameters.is_empty() || parameters.len() > 1 {
return;
}
let iter_trait_id = get_trait_def_id(cx, &paths::ITERATOR).unwrap();
Copy link

Choose a reason for hiding this comment

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

This will crash on any no_std crate or maybe even when linting the standard library itself. You should just return when this trait can't be found.

@camsteffen
Copy link
Contributor

camsteffen commented Sep 1, 2021

@Labelray Thanks for the PR. This is a good idea. I do have one concern though...

When GAT arrives (coming soon according to this blog post), iterators that are not impl Iterator will become a normal thing IIUC. Or at least normal enough to make this lint kind of annoying if it is on by default. So I guess this could be a restriction lint (as is currently in the PR), but then is it even worth having at all? @rust-lang/clippy

@flip1995
Copy link
Member

flip1995 commented Sep 2, 2021

Shouldn't this be covered by should_implement_trait?

@Labelray
Copy link
Contributor Author

Labelray commented Sep 2, 2021

Shouldn't this be covered by should_implement_trait?

I think not. [should_implement_trait] only detects fn next(&self) in impl blocks not implementing trait

@bors
Copy link
Contributor

bors commented Sep 2, 2021

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

@camsteffen
Copy link
Contributor

should_implement_trait is for a function in impl X that ought to be in impl SomeTrait for X so I think that is different because the iter method is just a convention and isn't in a trait.

@Manishearth
Copy link
Member

I think it's fine to have this lint until GATs arrive; the streaming iter trait might end up using a different signature, or we can check for both.

Bit concerned the lint name is too long though.

@Labelray
Copy link
Contributor Author

Labelray commented Sep 4, 2021

I think it's fine to have this lint until GATs arrive; the streaming iter trait might end up using a different signature, or we can check for both.

Bit concerned the lint name is too long though.

Will it be a good idea to name it as iter_without_impl and stream_without_implinstead? And is "the streaming iter trait" futures::stream::Stream?

Copy link
Contributor

@camsteffen camsteffen left a comment

Choose a reason for hiding this comment

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

For the lint name I'd suggest iter_not_returning_iterator.

Comment on lines 94 to 97
let parameters = fn_sig.decl.inputs;
if parameters.is_empty() || parameters.len() > 1 {
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

You can use if let [param] = fn_sig.decl.inputs. The if_chains can be collapsed. Can you also check that the parameter is &self?

@giraffate
Copy link
Contributor

@Labelray Labelray changed the title Add new lint returned_iter_not_implementing_iterator Add new lint iter_not_returning_iterator Sep 7, 2021
Copy link
Contributor

@camsteffen camsteffen left a comment

Choose a reason for hiding this comment

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

This lint can be in the pedantic group. Otherwise this is ready!

@camsteffen
Copy link
Contributor

Thanks! @bors r+

@bors
Copy link
Contributor

bors commented Sep 9, 2021

📌 Commit 8f88acd has been approved by camsteffen

@bors
Copy link
Contributor

bors commented Sep 9, 2021

⌛ Testing commit 8f88acd with merge 1a52478...

@bors
Copy link
Contributor

bors commented Sep 9, 2021

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: camsteffen
Pushing 1a52478 to master...

@bors bors merged commit 1a52478 into rust-lang:master Sep 9, 2021
@Labelray Labelray deleted the conflict branch September 9, 2021 02:04
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.

8 participants