Updated release notes for 0.11.0
Update AUTHORS.txt
Update to 0.11.0
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}
Updated release notes for 0.11.0
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.
librustc: Fix `expr_use_visitor` (and, transitively, the borrow check)
with overloaded calls.

This enforces the mutability and borrow restrictions around overloaded
calls.

Closes #14774.

[breaking-change]
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>
rustdoc: s/nil/unit/ internally.

Quick poll on IRC suggested that unit was the preferred name for ().
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]
travis: Move from travis_wait to time-passes

It's looking like we're still timing out all over the place with travis_wait
because the entire `make -j4 rustc-stage1` command is taking too long. Instead,
achieve roughly the same idea by just having `-Z time-passes` printing
information. We shouldn't have a pass that takes longer than 10 minutes in
isolation.
librustc: Properly compare implementation method type parameter bounds
with the corresponding trait parameter bounds.

This is a version of the patch in PR #12611 by Florian Hahn, modified to
address Niko's feedback.

It does not address the issue of duplicate type parameter bounds, nor
does it address the issue of implementation-defined methods that contain
*fewer* bounds than the trait, because Niko's review indicates that this
should not be necessary (and indeed I believe it is not). A test has
been added to ensure that this works.

This will break code like:

    trait Foo {
        fn bar<T:Baz>();
    }

    impl Foo for Boo {
        fn bar<T:Baz + Quux>() { ... }
        //             ^~~~ ERROR
    }

This will be rejected because the implementation requires *more* bounds
than the trait. It can be fixed by either adding the missing bound to
the trait:

    trait Foo {
        fn bar<T:Baz + Quux>();
        //             ^~~~
    }

    impl Foo for Boo {
        fn bar<T:Baz + Quux>() { ... }  // OK
    }

Or by removing the bound from the impl:

    trait Foo {
        fn bar<T:Baz>();
    }

    impl Foo for Boo {
        fn bar<T:Baz>() { ... }  // OK
        //       ^ remove Quux
    }

This patch imports the relevant tests from #2687, as well as the test
case in #5886, which is fixed as well by this patch.

Closes #2687.
Closes #5886.

[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.
Fix example in docs on documentation
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?
debuginfo: Make names of types in debuginfo reliable and omit source locations from debug info type descriptions.

So far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.
This commit makes the debuginfo module responsible for creating type names instead of using ppaux::ty_to_str() and brings type names, as they show up in the DWARF information, in line with GCC and Clang:

* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.
* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.

Care is also taken to reliably make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.

This commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.
Fortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be reenabled for type descriptions.