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

Fix doc nits #12880

Merged
merged 5 commits into from
Jun 15, 2024
Merged

Fix doc nits #12880

merged 5 commits into from
Jun 15, 2024

Conversation

bitfield
Copy link
Contributor

@bitfield bitfield commented Jun 3, 2024

Clippy is wonderful, and reading its lints is a great way to learn about Rust. While doing this, I noticed a few little copyedits, such as adding trailing periods to sentences, or tweaking wording very slightly to improve its readability. I hope you will accept these suggestions as an act of love for the project, with my thanks for all the maintainers' hard work.

changelog: Docs [ mut_range_bound ]: fix doc nits
changelog: Docs [ needless_for_each ]: fix doc nits
changelog: Docs [ arc_with_non_send_sync ]: fix doc nits
changelog: Docs [ allow_attributes ]: fix doc nits
changelog: Docs [ allow_attributes_without_reason ]: fix doc nits

@rustbot
Copy link
Collaborator

rustbot commented Jun 3, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Alexendoo (or someone else) some time within the next two weeks.

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 Jun 3, 2024
Comment on lines 34 to 35
/// for elem in v.iter() {
/// println!("{}", elem);
/// for elem in v {
/// println!("{elem}");
Copy link
Member

Choose a reason for hiding this comment

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

This isn't equivalent to the above code as it takes v by value. The println also should be updated in both if it's being changed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, @Alexendoo! Good catch, changed as suggested.

@bitfield
Copy link
Contributor Author

bitfield commented Jun 8, 2024

@rustbot review

@Alexendoo
Copy link
Member

Thanks!

@bors r+

@bors
Copy link
Contributor

bors commented Jun 15, 2024

📌 Commit 7c86db4 has been approved by Alexendoo

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jun 15, 2024

⌛ Testing commit 7c86db4 with merge 73c1bfb...

@bors
Copy link
Contributor

bors commented Jun 15, 2024

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: Alexendoo
Pushing 73c1bfb to master...

@bors bors merged commit 73c1bfb into rust-lang:master Jun 15, 2024
5 checks passed
@bitfield bitfield deleted the fix_doc_nits_b branch June 16, 2024 08:12
@bitfield
Copy link
Contributor Author

@Alexendoo thanks for your guidance on this one! I have a few more textual nits I've been collecting—from your point of view, what would be the best way to submit these?

  1. A single PR with lots of commits, one per lint
  2. A single PR with a single commit fixing lots of lints at once
  3. Multiple PRs, each with a small batch of fixes
  4. Something else

Smaller PRs are faster to review, but on the other hand batching a lot of changes together reduces the admin overhead of approval and merging—as a maintainer, which do you prefer?

@Alexendoo
Copy link
Member

I prefer single commits usually, single or multiple PRs are fine either way

I'd say don't split it up into multiple PRs if you have the work done already, but also you don't have to wait until you have done everything before opening a PR. It being in several chunks is perfectly fine if it works out like that

Whichever you go for, thank you for the contributions!

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.

4 participants