Per discussion on the tracking issue, naming `TryFrom`'s associated type
`Error` is generally more consistent with similar traits in the Rust
ecosystem, and what people seem to assume it should be called. It
also helps disambiguate from `Result::Err`, the most common "Err".

See
rust-lang#33417 (comment).

TryFrom<&str> and FromStr are equivalent, so have the latter provide the
former to ensure that. Using TryFrom in the implementation of
`str::parse` means types that implement either trait can use it.
When we're ready to stabilize `TryFrom`, we should update `FromStr` to
suggest implementing `TryFrom<&str>` instead for new code.

See
rust-lang#33417 (comment)
and
rust-lang#33417 (comment).

Refs rust-lang#33417.

This seems to match other uses of "be accessed" in the document.

… to be more precise.

Unfortunately it was reverted back to a broken state in
e06c515 by accident, so let's bring it forward
again!

…uron

Rename TryFrom's associated type and implement str::parse using TryFrom.

Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err".

See rust-lang#33417 (comment).

`TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to
suggest implementing `TryFrom<&str>` instead for new code.

See rust-lang#33417 (comment)
and rust-lang#33417 (comment).

Refs rust-lang#33417.

Library stabilizations for 1.17

Details of the stabilizations are available in the commits. Includes only library stabilizations; there are a couple of compiler stabilizations that should also be done for 1.17.

Will need a beta backport, which I will create after approval.

r? @alexcrichton

Remove unused param from bootstrap::clean::rm_rf

None

…wsxcv

Fix const not displayed in rustdoc

Fixes rust-lang#40331.

r? @rust-lang/docs

documented order of conversion between u32 an ipv4addr

This fixes rust-lang#40118

…uillaumeGomez

minor wording tweak to slice::{as_ptr, as_mut_ptr}

Per rust-lang#37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated.

r? @steveklabnik

Fix typo in mutex.rs docs

This seems to match other uses of "be accessed" in the document.

…sfackler

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.

…alexcrichton

Update the cargo submodule again

Unfortunately it was reverted back to a broken state in
e06c515 by accident, so let's bring it forward
again!

Closes rust-lang/cargo#3844