Update AUTHORS.txt
Updated release notes for 0.11.0
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]
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]
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.
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
auto merge of #15222 : alexcrichton/rust/relnotes, r=brson

Detailed notes have their skeleton [on the wiki](https://github.com/rust-lang/rust/wiki/Doc-detailed-release-notes) (and need filling out).
auto merge of #15313 : pcwalton/rust/overloaded-call-expr-use, r=alexcrichton

with overloaded calls.

This enforces the mutability and borrow restrictions around overloaded
calls.

[breaking-change]

Closes #12223.

r? @alexcrichton
Fix rotate_{left, right} for multiple of bitsize rotation amounts

Add additional rotation tests
auto merge of #15323 : alexcrichton/rust/no-travis-wait, r=huonw

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.
install: Correct libdir for Windows installs.

Platform-detection code from `configure` copied over to `install.sh`
in order to special case the lib dir being `bin` on Windows instead
of `lib`.

Short-term fix for #13810.
auto merge of #15325 : pcwalton/rust/trait-impl-bound-mismatch, r=pnkfelix

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]

r? @pnkfelix
auto merge of #15087 : iliekturtles/rust/13810-make-install-mingw32, r=brson

Short-term fix per @brson's comment: https://github.com/rust-lang/rust/issues/13810#issuecomment-43562843. Tested on Win7 x64 and Linux.

One possible issue is that `install.sh` doesn't have a `need_cmd` definition like `configure` does. Should this be ported over as well?

Platform-detection code from `configure` copied over to `install.sh` in
order to special case the lib dir being `bin` on Windows instead of
`lib`.

Short-term fix for #13810.
auto merge of #15324 : sneves/rust/master, r=alexcrichton

The current implementation of `rotate_left` and `rotate_right` are incorrect when the rotation amount is 0, or a multiple of the input's bitsize. When `n = 0`, the expression

    (self >> n) | (self << ($BITS - n))

results in a shift left by `$BITS` bits, which is undefined behavior (see https://github.com/rust-lang/rust/issues/10183), and currently results in a hardcoded `-1` value, instead of the original input value. Reducing `($BITS - n)` modulo `$BITS`, simplified to `(-n % $BITS)`, fixes this problem.
Improve code reuse between trans/_match.rs and check_match.rs

The specialization logic for patterns is really the same in both
exhaustiveness/reachability checking and codegen.
auto merge of #15078 : jakub-/rust/pattern-matching-refactor-vol-2, r=pnkfelix

I believe there's more commonality to be found there but maybe small steps are better. I'm also in the process of documenting what I can, I will see if I can add it to this PR.

It also seems to me that ideally some of this stuff (especially the pattern sanity check) could live as a separate compiler-agnostic module but I understand this may not be the right time (if not the worst) to start the process of modularising rustc.