docs: Small clarification on the usage of read_to_string and read_to_end trait methods

[kiseitai3]

Small clarification on the usage of read_to_string and read_to_end trait methods. The goal is to make it clear that these trait methods will become locked up if attempting to read to the end of stdin (which is a bit non-sensical unless the other end closes the pipe).

Fixes: #141714

[rustbot]

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[kiseitai3]

This is follow up work on #141935. If possible, reassign to @tgross35. A mistake was made in the previous PR. I attempted a rebase and one thing led to another and the branch became a mess, so I killed the branch. That autoclosed the old PR, so I opened a new one with changes more in line with what Trevor asked.

Sorry, but I hope this PR is more like what is expected in this project.

[tgross35]

If possible, reassign to @tgross35

I'll let you do this yourself for the experience :) you can request reviews by posting a comment, see rustbot's guidelines:

Use r? to explicitly pick a reviewer

[tgross35]

Also it looks like you accidentally picked up a submodule change here. There's about 1000 different ways to fix this but if you need a suggestion, I would do something like this:

# Reset to the point where your branch forked from `master`. The reset will get rid
# of your commit and mark all of the files as staged
git reset "$(git merge-base HEAD master)"

# Add the thing you care about
git add library/std

# Get ride of the unintentional changes
git restore src/doc

# Re-commit the files (now only what you care about) using 🪄 magic 🪄 to
# reuse the commit message you have now
git commit -C HEAD@{1}

# Update this PR
git push --force-with-lease

Also, you can always check exactly what your PR will look like before pushing with git diff "$(git merge-base HEAD master)", to avoid things like whatever bad luck you ran into with #141935 (comment).

(happy to help with git stuff if you have further questions)

[kiseitai3]

I'm not using git from the terminal. I am using it through RustRover and I assumed it had only picked up my modified file since I had not changed anything. However, I do see failure messages for what appear to be automatic attempts at running repository actions. I did not look closely since I have very little personal time for coding and I kinda wanted to move on with a milestone in my own personal project. I will need to correct that in my IDE settings. That's annoying.

I have used git in the terminal before so maybe that would have given me a clue. Maybe one of these days I will convert to Vim and embrace the terminal more (which is ironic considering I use the terminal 24/7 at work).

r? @tgross35

P.S. > Completely missed the docs changes getting picked up.

[tgross35]

This looks great to me, thank you for the changes! You don't need to mention me in the commit though, just describe what you did since it is your work :)

For the submodule thing - git usually marks submodules as unstaged changes if you don't update them when changing branches / rebasing / etc, so anything that does git add . or git commit -a to commit all files will pick them up even when you never touched the file. Just submodules being a bit annoying, unfortunately.

[kiseitai3]

This looks great to me, thank you for the changes! You don't need to mention me in the commit though, just describe what you did since it is your work :)

For the submodule thing - git usually marks submodules as unstaged changes if you don't update them when changing branches / rebasing / etc, so anything that does git add . or git commit -a to commit all files will pick them up even when you never touched the file. Just submodules being a bit annoying, unfortunately.

I have learned quite a bit from you on git. Since I don't solely use git on the terminal or via IDEs, I don't have as deep experience with terminal git. I am going to save the instructions above to a cheatsheet to recover from bad commits in the future.

Thank you!

P.S. > I wish I was compiler designer smart. Impressive work you all have done. With that said, my hope is to make Rust core to my development so maybe I will get more chances to contribute in the future.

[tgross35]

Recovering from bad commits becomes mandatory learning at some point 😆

P.S. > I wish I was compiler designer smart.

You are, you just made your first contribution to a rather impressive project :) Welcome and thank you for the persistence here!

I force pushed your branch to make the commit message match this PR's title, so with that:

@bors r+ rollup

[bors]

📌 Commit 7d7fedb has been approved by tgross35

It is now in the queue for this repository.