Rewrite `io::BufRead` doc examples to better demonstrate behaviors.
Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:
* Relying on run-time data means we can't show concrete examples of how
these methods work up-front. The user is required to run them in order
to see how they behave.
* If the user tries to run an example in the playpen, it won't work
because the playpen doesn't support user input to stdin.
In #29370 it's noted that for "the Note shouldn't be one, and should come before
the examples." This commit changes the positioning of the section and removes
wording that said take note in order for it to flow better with the surrounding
text and it's new position.
Fix formatting in the docs for std::process::Command::envs()
An empty line between the *Basic usage:* text and the example is required to properly format the code. Without the empty line, the example is not formatted as code.
[Here](https://doc.rust-lang.org/std/process/struct.Command.html#method.envs) you can see the current (improper) formatting.
The person who originally wrote the example forgot to include this attribute.
This caused Travis CI to fail on commit 9b0a4a4e97 (#40794), which just fixed
formatting in the description of std::process::Command::envs().
An empty line between the "Basic usage:" text and the example is required to
properly format the code. Without the empty line, the example is not formatted
as code.
Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:
* Relying on run-time data means we can't show concrete examples of how
these methods work up-front. The user is required to run them in order
to see how they behave.
* If the user tries to run an example in the playpen, it won't work
because the playpen doesn't support user input to stdin.
... even if contained `Vec` is not empty. E. g. for
```
let v = vec![10u8, 20];
let mut c = io::Cursor::new(v);
c.write_all(b"aaaa").unwrap();
println!("{:?}", c.into_inner());
```
result is
```
[97, 97, 97, 97]
```
and not
```
[10, 20, 97, 97, 97, 97]
```
This alters the stdio code on Windows to always call `GetStdHandle` whenever the
stdio read/write functions are called as this allows us to track changes to the
value over time (such as if a process calls `SetStdHandle` while it's running).
Closes#40490
This replaces the `std::collections:#️⃣:table::RevMoveBuckets`
iterator with a simpler `while` loop. This iterator was only used for
dropping the remaining elements of a `RawTable`, so instead we can just
loop through directly and drop them in place.
This should be functionally equivalent to the former code, but a little
easier to read. I was hoping it might have some performance benefit
too, but it seems the optimizer was already good enough to see through
the iterator -- the generated code is nearly the same. Maybe it will
still help if an element type has more complicated drop code.
Extract book into a submodule
Part of https://github.com/rust-lang/rust/issues/39588
We probably don't want to land this till after the beta branches on friday, but would still ❤️ a review from @alexcrichton , since I am a rustbuild noob.
This pr:
1. removes the book
2. adds it back in as a submodule
3. the submodule includes both the old book and the new book
4. it also includes an index page explaining the difference in editions
5. it also includes redirect pages for the old book URLs.
6. so we build all that stuff too.
r? @alexcrichton
Fix race condition in fs::create_dir_all
The code would crash if the directory was created after create_dir_all
checked whether the directory already existed. This was contrary to
the documentation which claimed to create the directory if it doesn't
exist, implying (but not stating) that there would not be a failure
due to the directory existing.
Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision
Noticed while reading docs just now.
It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess. But unless there's an API guarantee that this is the case, the wording seems over-precise. Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction? I don't think the quality of output in that case would depend on when the RNG was created. Yet it seems to me like it could well be a valid source of randomness when computing the initial seed.
For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining. That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.
Ignore the type of error altogether. The rationale is: it doesn't matter
what was the problem if the directory is there. In the previous versions
if the directory was there already we wouldn't even attempt to create
it, so we wouldn't know about the problem neither.
Make test path length smaller in `concurrent_recursive_mkdir` test.
It is more robust to not fail if any directory in a path was created
concurrently. This change lifts rustc internal `create_dir_racy` that
was created to handle such conditions to be new `create_dir_all`
implementation.
std: remove a workaround for privacy limitations
`std:🧵:Thread` implements a non-exported `NewThread` trait to allow for internal-only use of `Thread::new`. Nowadays we have `pub(crate)`, which accomplishes the same thing but much more idiomatically.
Rustdoc handles this correctly (I checked and I didn't see `Thread::new` on the rustdoc entry for `Thread` with this change), and the stage1 `rustc` emits the correct error still (I'm assuming that the stage1 compiler uses my `libstd`?):
```
$ ./build/x86_64-apple-darwin/stage1/bin/rustc test.rs
error: method `new` is private
--> test.rs:4:18
|
4 | let thread = thread::Thread::new(None);
| ^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
