Since #24783, the style guidelines recommend that unit tests should live in a submodule `tests` rather than `test` to not clash with the possible use of libtest. This is especially important for benchmark tests as they require libtest. Fixes#24923.
There are still quite a few ignored Android tests kicking around, most of which were added in 445faca844, which has a pretty unfortunate commit message.
r? @alexcrichton
core: Fix size_hint for signed integer `Range<T>` iterators
There was an overflow bug in .size_hint() for signed iterators, which
produced an hilariously incorrect size or an overflow panic.
Incorrect size is a serious bug since the iterators are marked
ExactSizeIterator. (And leads to abort() on (-1i8..127).collect() when
the collection tries to preallocate too much).
> (-1i8..127).size_hint()
(18446744073709551488, Some(18446744073709551488))
Bug found using quickcheck.
Fixes#24851
Implement Vec::drain(\<range type\>) from rust-lang/rfcs#574, tracking issue #23055.
This is a big step forward for vector usability. This is an introduction of an API for removing a range of *m* consecutive elements from a vector, as efficently as possible.
New features:
- Introduce trait `std::collections::range::RangeArgument` implemented by all four built-in range types.
- Change `Vec::drain()` to use `Vec::drain<R: RangeArgument>(R)`
Implementation notes:
- Use @Gankro's idea for memory safety: Use `set_len` on the source vector when creating the iterator, to make sure that the part of the vector that will be modified is unreachable. Fix up things in Drain's destructor — but even if it doesn't run, we don't expose any moved-out-from slots of the vector.
- This `.drain<R>(R)` very close to how it is specified in the RFC.
- Introduced as unstable
- Drain reuses the slice iterator — copying and pasting the same iterator pointer arithmetic again felt very bad
- The `usize` index as a range argument in the RFC is not included. The ranges trait would have to change to accomodate it.
Please help me with:
- Name and location of the new ranges trait.
- Design of the ranges trait
- Understanding Niko's comments about variance (Note: for a long time I was using a straight up &mut Vec in the iterator, but I changed this to permit reusing the slice iterator).
Previous PR and discussion: #23071
These commits build on [some great work on reddit](http://www.reddit.com/r/rust/comments/33boew/weekend_experiment_link_rust_programs_against/) for adding MUSL support to the compiler. This goal of this PR is to enable a `--target x86_64-unknown-linux-musl` argument to the compiler to work A-OK. The outcome here is that there are 0 compile-time dependencies for a MUSL-targeting build *except for a linker*. Currently this also assumes that MUSL is being used for statically linked binaries so there is no support for dynamically linked binaries with MUSL.
MUSL support largely just entailed munging around with the linker and where libs are located, and the major highlights are:
* The entirety of `libc.a` is included in `liblibc.rlib` (statically included as an archive).
* The entirety of `libunwind.a` is included in `libstd.rlib` (like with liblibc).
* The target specification for MUSL passes a number of ... flavorful options! Each option is documented in the relevant commit.
* The entire test suite currently passes with MUSL as a target, except for:
* Dynamic linking tests are all ignored as it's not supported with MUSL
* Stack overflow detection is not working MUSL yet (I'm not sure why)
* There is a language change included in this PR to add a `target_env` `#[cfg]` directive. This is used to conditionally build code for only MUSL (or for linux distros not MUSL). I highly suspect that this will also be used by Windows to target MSVC instead of a MinGW-based toolchain.
To build a compiler targeting MUSL you need to follow these steps:
1. Clone the current MUSL repo from `git://git.musl-libc.org/musl`. Build this as usual and install it.
2. Clone and build LLVM's [libcxxabi](http://libcxxabi.llvm.org/) library. Only the `libunwind.a` artifact is needed. I have tried using upstream libunwind's source repo but I have not gotten unwinding to work with it unfortunately. Move `libunwind.a` adjacent to MUSL's `libc.a`
3. Configure a Rust checkout with `--target=x86_64-unknown-linux-musl --musl-root=$MUSL_ROOT` where `MUSL_ROOT` is where you installed MUSL in step 1.
I hope to improve building a copy of libunwind as it's still a little sketchy and difficult to do today, but other than that everything should "just work"! This PR is not intended to include 100% comprehensive support for MUSL, as future modifications will probably be necessary.
dropck: Remove `Copy` from special-cased traits
Fix#24895.
[breaking-change]
What does this break? Basically, code that implements `Drop` and is
using `T:Copy` for one of its type parameters and is relying on the
Drop Check rule not applying to it.
Here is an example:
```rust
#![allow(dead_code,unused_variables,unused_assignments)]
struct D<T:Copy>(T);
impl<T:Copy> Drop for D<T> { fn drop(&mut self) { } }
trait UserT { fn c(&self) { } }
impl<T:Copy> UserT for T { }
struct E<T:UserT>(T);
impl<T:UserT> Drop for E<T> { fn drop(&mut self) { } }
// This one will start breaking.
fn foo() { let (d2, d1); d1 = D(34); d2 = D(&d1); }
#[cfg(this_one_does_and_should_always_break)]
fn bar() { let (e2, e1); e1 = E(34); e2 = E(&e1); }
fn main() {
foo();
}
```
There were a few test cases to fix:
* Dynamic libraries are not supported with MUSL right now, so all of those
related test which force or require dylibs are ignored.
* Looks like the default stack for MUSL is smaller than glibc, so a few stack
allocations in benchmarks were boxed up (shouldn't have a perf impact).
* Some small linkage tweaks here and there
* Out-of-stack detection does not currently work with MUSL
[breaking-change]
What does this break? Basically, code that implements `Drop` and is
using `T:Copy` for one of its type parameters and is relying on the
Drop Check rule not applying to it.
Here is an example:
```rust
#![allow(dead_code,unused_variables,unused_assignments)]
struct D<T:Copy>(T);
impl<T:Copy> Drop for D<T> { fn drop(&mut self) { } }
trait UserT { fn c(&self) { } }
impl<T:Copy> UserT for T { }
struct E<T:UserT>(T);
impl<T:UserT> Drop for E<T> { fn drop(&mut self) { } }
// This one will start breaking.
fn foo() { let (d2, d1); d1 = D(34); d2 = D(&d1); }
#[cfg(this_one_does_and_should_always_break)]
fn bar() { let (e2, e1); e1 = E(34); e2 = E(&e1); }
fn main() {
foo();
}
```
This error indicates that a constant references itself.
All constants need to resolve to a value in an acyclic manner.
For example, neither of the following can be sensibly compiled:
```
const X: u32 = X;
```
```
const X: u32 = Y;
const Y: u32 = X;
```
