Add a missing verb to the description of std::process::ExitStatus::success()
"Signal termination not considered" -> "Signal termination **is** not considered"
The first line of the description was rewrapped so it fits into 80 characters.
Fix docs: BufReader/File doesn't need to be mut
Neither `BufReader` nor `File` need to be declared `mut` for most of these examples. The cookbook example using `BufReader` doesn't declare them as `mut` either (https://brson.github.io/rust-cookbook/basics.html#ex-std-read-lines).
Improve panic docs for Instant::duration_since
The docs for Instant::duration_since has a confusing section on panicking. It's
much more clear without the second two sentences of description.
"Signal termination not considered" -> "Signal termination is not considered"
The first line of the description was rewrapped so it fits into 80 characters.
float_bits_conv made it into 1.20
It seems that my PR to stabilize the `float_bits_conv` feature got merged before beta branched, which means I'm lucky, and the stabilization makes it into Rust 1.20. As it was against my expectations, the version number has to be corrected from 1.21 to 1.20.
Please also apply this PR to the beta branch.
`std::time::Duration`: improve _precision_ of terminology in docs
Changed wording of docs on `std::time::Duration` for better clarity w.r.t. the contents of the type and the purpose of its methods. (Specifically, removed the use of the word "precision" to describe the fractional part of the `Duration` because "precision" is more properly used to describe how _precise_ a value is, i.e. its granularity in this case.)
Stabilize float_bits_conv for Rust 1.21
Stabilizes the `float_bits_conv` lib feature for the 1.20 release of Rust. I've initially implemented the feature in #39271 and later made PR #43025 to output quiet NaNs even on platforms with different encodings, which seems to have been the only unresolved issue of the API.
Due to PR #43025 being only applied to master this stabilisation can't happen for Rust 1.19 through the usual "stabilisation on beta" system that is being done for library APIs.
r? @BurntSushi
closes#40470.
support pub(restricted) in thread_local! (round 2)
Resurrected #40984 now that the issue blocking it was fixed. Original description:
`pub(restricted)` was stabilized in #40556 so let's go!
Here is a [playground](https://play.rust-lang.org/?gist=f55f32f164a6ed18c219fec8f8293b98&version=nightly&backtrace=1).
I changed the interface of `__thread_local_inner!`, which is supposedly unstable but this is not checked for macros (#34097 cc @petrochenkov @jseyfried), so this may be an issue.
windows::fs::symlink_dir: fix example to actually use symlink_dir
I don't have a windows machine, so I couldn't test if this doctest still works -- but it looks trivial enough. (I know, famous last words.)
Implement fs::rename in sys::redox
This uses a simple implementation of copy + unlink. Redox does not have a rename or link system call for a faster implementation.
Document what happens on failure in path ext is_file is_dir
r? @steveklabnik
Also, what other ways could there be an error that gets discarded and returns false? Should we list them all? Should we say that any errors trying to access the metadata at that path causes it to return false, even if there might be a file or directory there?
Should I add a See also link to the original functions that do return Results?
Thread local try with
https://github.com/rust-lang/rfcs/pull/2030 was turned into this PR (the RFC was closed, but it looks like just a PR should be good).
See also: state stabilization issue: #27716
`try_with` is used in two places in std: stdio and thread_info. In stdio, it would be better if the result was passed to the closure, but in thread_info, it's better as is where the result is returned from the function call. I'm not sure which is better, but I prefer the current way as it better represents the scope.
Add warning to BufWriter documentation
When using `BufWriter`, it is very easy to unintentionally ignore errors, because errors which occur when flushing buffered data when the `BufWriter` is dropped are ignored. This has been noted in a couple places: #32677, #37045.
There has been some discussion about how to fix this problem in #32677, but no solution seems likely to land in the near future. For now, anyone who wishes to have robust error handling must remember to manually call `flush()` on a `BufWriter` before it is dropped. Until a permanent fix is in place, it seems worthwhile to add a warning to that effect to the documentation.
