std: make sure HashMap from_iter uses random initialization by default

It turns out that HashMap's from_iter implementation was being
initialized without the sip keys being randomized. This adds
a custom default hasher that should avoid this potential vulnerability.
std: micro optimize Hash{Map,Set}::{new,with_capacity}
std: move the hash docstring over to std::hash.
test: Add tests for issue #12223, "drop allowed while active borrows
still in scope".

This issue was fixed by PR #12828 and #5781. All that was left was to
add tests.

Closes #12223.
Rename recvfrom -> recv_from, sendto -> send_to.

POSIX has recvfrom(2) and sendto(2), but their name seem not to be
suitable with Rust. We already renamed getpeername(2) and
getsockname(2), so I think it makes sense.

Alternatively, `receive_from` would be fine. However, we have `.recv()`
so I chose `recv_from`.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Add `recvfrom` and `sendto`.

We leave them for compatibility, but mark them as deprecated.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
rustc: Remove `&str` indexing from the language.

Being able to index into the bytes of a string encourages
poor UTF-8 hygiene. To get a view of `&[u8]` from either
a `String` or `&str` slice, use the `as_bytes()` method.

Closes #12710.

[breaking-change]
auto merge of #15085 : brson/rust/stridx, r=alexcrichton

Being able to index into the bytes of a string encourages
poor UTF-8 hygiene. To get a view of `&[u8]` from either
a `String` or `&str` slice, use the `as_bytes()` method.

Closes #12710.

[breaking-change]

If the diffstat is any indication this shouldn't have a huge impact but it will have some. Most changes in the `str` and `path` module. A lot of the existing usages were in tests where ascii is expected. There are a number of other legit uses where the characters are known to be ascii.
auto merge of #15257 : erickt/rust/hashmap, r=alexcrichton

While `HashMap::new` and `HashMap::with_capacity` were being initialized with a random `SipHasher`, it turns out that `HashMap::from_iter` was just using the default instance of `SipHasher`, which wasn't randomized. This closes that bug, and also inlines some important methods.
auto merge of #15265 : omasanori/rust/udp, r=alexcrichton

POSIX has recvfrom(2) and sendto(2), but their name seem not to be suitable with Rust. We already renamed getpeername(2) and getsockname(2), so I think it makes sense.

Alternatively, `receive_from` would be fine. However, we have `.recv()` so I chose `recv_from`.

What do you think? If this makes sense, should I provide `recvfrom` and `sendto` deprecated methods just calling new methods for compatibility?
auto merge of #15310 : pcwalton/rust/tests-for-12223, r=brson

still in scope".

This issue was fixed by PR #12828 and #5781. All that was left was to
add tests.

Closes #12223.
Apply stability attributes to std::comm

* channel() - #[unstable]. This will likely remain forever

* sync_channel(n: int) - #[unstable with comment]. Concerns have ben raised
  about the usage of the term "synchronous channel" because that generally only
  applies to the case where n == 0. If n > 0 then these channels are often
  referred to as buffered channels.

* Sender::send(), SyncSender::send(), Receiver::recv() - #[experimental]. These
  functions directly violate the general guideline of not providing a failing
  and non-failing variant. These functions were explicitly selected for being
  excused from this guideline, but recent discussions have cast doubt on that
  decision. These functions are #[experimental] for now until a decision is made
  as they are candidates for removal.

* Sender::send_opt(), SyncSender::send_opt(), Receiver::recv_opt() - #[unstable
  with a comment]. If the above no-`_opt` functions are removed, these functions
  will be renamed to the non-`_opt` variants.

* SyncSender::try_send(), Receiver::try_recv() - #[unstable with a comment].
  These return types of these functions to not follow general conventions. They
  are consistent with the rest of the api, but not with the rest of the
  libraries. Until their return types are nailed down, these functions are
  #[unstable].

* Receiver::iter() - #[unstable]. This will likely remain forever.

* std::com::select - #[experimental]. The functionality is likely to remain in
  some form forever, but it is highly unlikely to remain in its current form. It
  is unknown how much breakage this will cause if and when the api is
  redesigned, so the entire module and its components are all experimental.

* DuplexStream - #[deprecated]. This type is not composable with other channels
  in terms of selection or other expected locations. It can also not be used
  with ChanWriter and ChanReader, for example. Due to it being only lightly
  used, and easily replaced with two channels, this type is being deprecated and
  slated for removal.

* Clone for {,Sync}Sender - #[unstable]. This will likely remain forever.
auto merge of #15286 : alexcrichton/rust/channel-stability, r=cmr

* channel() - #[unstable]. This will likely remain forever

* sync_channel(n: int) - #[unstable with comment]. Concerns have ben raised
  about the usage of the term "synchronous channel" because that generally only
  applies to the case where n == 0. If n > 0 then these channels are often
  referred to as buffered channels.

* Sender::send(), SyncSender::send(), Receiver::recv() - #[experimental]. These
  functions directly violate the general guideline of not providing a failing
  and non-failing variant. These functions were explicitly selected for being
  excused from this guideline, but recent discussions have cast doubt on that
  decision. These functions are #[experimental] for now until a decision is made
  as they are candidates for removal.

* Sender::send_opt(), SyncSender::send_opt(), Receiver::recv_opt() - #[unstable
  with a comment]. If the above no-`_opt` functions are removed, these functions
  will be renamed to the non-`_opt` variants.

* SyncSender::try_send(), Receiver::try_recv() - #[unstable with a comment].
  These return types of these functions to not follow general conventions. They
  are consistent with the rest of the api, but not with the rest of the
  libraries. Until their return types are nailed down, these functions are
  #[unstable].

* Receiver::iter() - #[unstable]. This will likely remain forever.

* std::com::select - #[experimental]. The functionality is likely to remain in
  some form forever, but it is highly unlikely to remain in its current form. It
  is unknown how much breakage this will cause if and when the api is
  redesigned, so the entire module and its components are all experimental.

* DuplexStream - #[deprecated]. This type is not composable with other channels
  in terms of selection or other expected locations. It can also not be used
  with ChanWriter and ChanReader, for example. Due to it being only lightly
  used, and easily replaced with two channels, this type is being deprecated and
  slated for removal.

* Clone for {,Sync}Sender - #[unstable]. This will likely remain forever.
Change exhaustiveness analysis to permit multiple constructors per pattern

Slice patterns are different from the rest in that a single slice pattern
does not have a distinct constructor if it contains a variable-length subslice
pattern. For example, the pattern [a, b, ..tail] can match a slice of length 2, 3, 4
and so on.

As a result, the decision tree for exhaustiveness and redundancy analysis should
explore each of those constructors separately to determine if the pattern could be useful
when specialized for any of them.
auto merge of #15186 : jakub-/rust/issue-15104, r=pnkfelix