This branch cleans up overloaded operator resolution so that it is strictly based on the traits in `ops`, rather than going through the normal method lookup mechanism. It also adds full support for autoderef to overloaded index (whereas before autoderef only worked for non-overloaded index) as well as for the slicing operators.
This is a [breaking-change]: in the past, we were accepting combinations of operands that were not intended to be accepted. For example, it was possible to compare a fixed-length array and a slice, or apply the `!` operator to a `&int`. See the first two commits in this pull-request for examples.
One downside of this change is that comparing fixed-length arrays doesn't always work as smoothly as it did before. Before this, comparisons sometimes worked due to various coercions to slices. I've added impls for `Eq`, `Ord`, etc for fixed-lengths arrays up to and including length 32, but if the array is longer than that you'll need to either newtype the array or convert to slices. Note that this plays better with deriving in any case than the previous scheme.
Fixes#4920.
Fixes#16821.
Fixes#15757.
cc @alexcrichton
cc @aturon
This is a follow-up to [RFC PR #173](https://github.com/rust-lang/rfcs/pull/173). I was told there that changes like this don't need to go through the RFC process, so I'm submitting this directly.
This PR introduces `ToSocketAddr` trait as defined in said RFC. This trait defines a conversion from different types like `&str`, `(&str, u16)` or even `SocketAddr` to `SocketAddr`. Then this trait is used in all constructor methods for `TcpStream`, `TcpListener` and `UdpSocket`.
This unifies these constructor methods - previously they were using different types of input parameters (TCP ones used `(&str, u16)` pair while UDP ones used `SocketAddr`), which is not consistent by itself and sometimes inconvenient - for example, when the address initially is available as `SocketAddr`, you still need to convert it to string to pass it to e.g. `TcpStream`. This is very prominently demonstrated by the unit tests for TCP functionality. This PR makes working with network objects much like with `Path`, which also uses similar trait to be able to be constructed from `&[u8]`, `Vec<u8>` and other `Path`s.
This is a breaking change. If constant literals were used before, like this:
```rust
TcpStream::connect("localhost", 12345)
```
then the nicest fix is to change it to this:
```rust
TcpStream::connect("localhost:12345")
```
If variables were used before, like this:
```rust
TcpStream::connect(some_address, some_port)
```
then the arguments should be wrapped in another set of parentheses:
```rust
TcpStream::connect((some_address, some_port))
```
`UdpSocket` usages won't break because its constructor method accepted `SocketAddr` which implements `ToSocketAddr`, so `bind()` calls:
```rust
UdpSocket::bind(some_socket_addr)
```
will continue working as before.
I haven't changed `UdpStream` constructor because it is deprecated anyway.
Key points are:
1. `a + b` maps directly to `Add<A,B>`, where `A` and `B` are the types of `a` and `b`.
2. Indexing and slicing autoderefs consistently.
This fixes some metadata/AST encoding problems that lead to ICEs. The way this is currently handled will need revisiting if abstract return types are added, as unboxed closure types from extern crates could show up without being inlined into the local crate.
Closes#16790 (I think this was fixed earlier by accident and just needed a test case)
Closes#18378Closes#18543
r? @pcwalton
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
Unicode characters and strings.
Use `\u0080`-`\u00ff` instead. ASCII/byte literals are unaffected.
This PR introduces a new function, `escape_default`, into the ASCII
module. This was necessary for the pretty printer to continue to
function.
RFC #326.
Closes#18062.
[breaking-change]
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
- The `BytesContainer::container_into_owned_bytes` method has been removed
- Methods that used to take `BytesContainer` implementors by value, now take them by reference. In particular, this breaks some uses of Path:
``` rust
Path::new("foo") // Still works
path.join(another_path) -> path.join(&another_path)
```
[breaking-change]
---
Re: `container_into_owned_bytes`, I've removed it because
- Nothing in the whole repository uses it
- Takes `self` by value, which is incompatible with unsized types (`str`)
The alternative to removing this method is to split `BytesContainer` into `BytesContainer for Sized?` and `SizedBytesContainer: BytesContainer + Sized`, where the second trait only contains the `container_into_owned_bytes` method. I tried this alternative [in another branch](https://github.com/japaric/rust/commits/bytes) and it works, but it seemed better not to create a new trait for an unused method.
Re: Breakage of `Path` methods
We could use the idea that @alexcrichton proposed in #18457 (add blanket `impl BytesContainer for &T where T: BytesContainer` + keep taking `T: BytesContainer` by value in `Path` methods) to avoid breaking any code.
r? @aturon
cc #16918
Add lint for checking exceeding bitshifts #17713
It also const-evaluates the shift width (RHS) to check more complex shifts like `1u8 << (4+5)`.
The lint-level is set to `Warn` but perhaps it must be `Deny` as in llvm exceeding bitshifts are undefined as @ben0x539 stated in #17713
* Moves multi-collection files into their own directory, and splits them into seperate files
* Changes exports so that each collection has its own module
* Adds underscores to public modules and filenames to match standard naming conventions
(that is, treemap::{TreeMap, TreeSet} => tree_map::TreeMap, tree_set::TreeSet)
* Renames PriorityQueue to BinaryHeap
* Renames SmallIntMap to VecMap
* Miscellanious fallout fixes
[breaking-change]
