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.

Sign up for GitHub

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

Jump to bottom

Issue 8733: Suggest str.lines when splitting at hard-coded newlines #11987

Merged
merged 1 commit into from
Dec 31, 2023
Merged

Issue 8733: Suggest str.lines when splitting at hard-coded newlines #11987

merged 1 commit into from
Dec 31, 2023

Conversation

torfsen
Copy link
Contributor

@torfsen torfsen commented Dec 19, 2023

Fixes #8733.

changelog: [`splitting_strings_at_newlines`]: New lint that suggests `str.lines` over splitting at hard-coded newlines

This is my first PR to Clippy and one of my first Rust PRs in general -- please feel free to nitpick, I'm thankful for any opportunity to learn! I'd be especially interested in feedback to the following points:

  • Is checking for '\n', "\n", and "\r\n" as arguments to split enough, or should we do more (e.g. checking for constants that have those values if that is possible)?
  • Could the code be written in a more idiomatic way?
  • Is the default ".." for snippet a good choice? I copied it from other uses of snippet in the code base, but I'm not entirely sure.
  • Is the category suspicious a good choice?
  • Is the suggestion applicability MaybeIncorrect a good choice? I used it because the return type of lines is not exactly the same as that of split.

@rustbot
Copy link
Collaborator

rustbot commented Dec 19, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Jarcho (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Dec 19, 2023
y21
y21 reviewed Dec 20, 2023
View reviewed changes
tests/ui/splitting_strings_at_newlines.rs Outdated Show resolved Hide resolved
clippy_lints/src/splitting_strings_at_newlines.rs Outdated Show resolved Hide resolved
clippy_lints/src/splitting_strings_at_newlines.rs Outdated Show resolved Hide resolved
clippy_lints/src/splitting_strings_at_newlines.rs Outdated Show resolved Hide resolved
torfsen added a commit to torfsen/rust-clippy that referenced this pull request Dec 21, 2023
@torfsen
8733: Simplify code
c05c79e 
Following the suggestions of @y21 in rust-lang#11987.
Jarcho
Jarcho requested changes Dec 24, 2023
View reviewed changes
Copy link
Contributor

@Jarcho Jarcho left a comment

Choose a reason for hiding this comment

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

This should also have a check for is_const_evaluatable on the receiver for trim. If the string is a constant then at best using lines makes no difference.

To answer some of your questions:

  • No need to check for other ways of writing the constant. I would have even suggest not linting if the result came from a named constant anyways.
  • The default snippet value only gets used with invalid spans, or when the source code is not available. i.e. It basically never happens.
  • This would probably be better off as pedantic. Most of the results from GitHub are for code challenges where it doesn't matter anyways and may have been an intentional choice. Some of the results are for parsing unix config files where splitting on '\n' is technically the correct choice. "\r\n" would be the correct choice for parsing Windows batch scripts.

clippy_lints/src/methods/str_split.rs Outdated Show resolved Hide resolved
clippy_lints/src/methods/str_split.rs Outdated Show resolved Hide resolved
clippy_lints/src/methods/str_split.rs Outdated Show resolved Hide resolved
clippy_lints/src/methods/str_split.rs Outdated Show resolved Hide resolved
@torfsen
Copy link
Contributor Author

torfsen commented Dec 25, 2023

This should also have a check for is_const_evaluatable on the receiver for trim. If the string is a constant then at best using lines makes no difference.

Done.

To answer some of your questions: [...]

Thanks!

This would probably be better off as pedantic. Most of the results from GitHub are for code challenges where it doesn't matter anyways and may have been an intentional choice. Some of the results are for parsing unix config files where splitting on '\n' is technically the correct choice. "\r\n" would be the correct choice for parsing Windows batch scripts.

Fixed.

@torfsen torfsen requested a review from Jarcho December 25, 2023 12:35
Jarcho
Jarcho approved these changes Dec 25, 2023
View reviewed changes
Copy link
Contributor

@Jarcho Jarcho left a comment

Choose a reason for hiding this comment

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

Just one little note with the docs I missed last time. Otherwise this looks good.

@bors
Copy link
Contributor

bors commented Dec 26, 2023

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

@torfsen torfsen force-pushed the 8733-Suggest-str.lines-when-splitting-at-newlines branch from 21fab26 to a0ef520 Compare December 27, 2023 13:09
torfsen added a commit to torfsen/rust-clippy that referenced this pull request Dec 27, 2023
@torfsen
8733: Simplify code
86ed828 
Following the suggestions of @y21 in rust-lang#11987.
@Jarcho
Copy link
Contributor

Jarcho commented Dec 30, 2023

All good. Can you squash the commits down please.

@bors
Copy link
Contributor

bors commented Dec 30, 2023

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

@torfsen
8733: Suggest str.lines when splitting at hard-coded newlines
fe35e08 
Adds a new `splitting_strings_at_newlines` lint that suggests to use
`str.lines` instead of splitting a trimmed string at hard-coded
newlines.
@torfsen torfsen force-pushed the 8733-Suggest-str.lines-when-splitting-at-newlines branch from a0ef520 to fe35e08 Compare December 31, 2023 12:53
@torfsen
Copy link
Contributor Author

torfsen commented Dec 31, 2023

@Jarcho: Rebased and squashed.

@Jarcho
Copy link
Contributor

Jarcho commented Dec 31, 2023

Thank you. @bors r+

@bors
Copy link
Contributor

bors commented Dec 31, 2023

📌 Commit fe35e08 has been approved by Jarcho

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Dec 31, 2023

⌛ Testing commit fe35e08 with merge a89eb85...

@bors
Copy link
Contributor

bors commented Dec 31, 2023

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: Jarcho
Pushing a89eb85 to master...

@bors bors merged commit a89eb85 into rust-lang:master Dec 31, 2023
8 checks passed
@bors bors mentioned this pull request Dec 31, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@y21 y21 y21 left review comments

@Jarcho Jarcho Jarcho approved these changes

Assignees

@Jarcho Jarcho

Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Suggest using string.lines() when string.split("\n"), or string.split("\r\n") is seen
5 participants
@torfsen @rustbot @bors @Jarcho @y21