Improve tests and benchmarks for slice::sort and slice::sort_unstable
This PR just hardens the tests and improves benchmarks.
More specifically:
1. Benchmarks don't generate vectors in `Bencher::iter` loops, but simply clone pregenerated vectors.
2. Benchmark `*_strings` doesn't allocate Strings in `Bencher::iter` loops, but merely clones a `Vec<&str>`.
3. Benchmarks use seeded `XorShiftRng` to be more consistent.
4. Additional tests for `slice::sort` are added, which test sorting on slices with several ascending/descending runs. The implementation identifies such runs so it's a good idea to test that scenario a bit.
5. More checks are added to `run-pass/vector-sort-panic-safe.rs`. Sort algorithms copy elements around a lot (merge sort uses an auxilliary buffer and pdqsort copies the pivot onto the stack before partitioning, then writes it back into the slice). If elements that are being sorted are internally mutable and comparison function mutates them, it is important to make sure that sort algorithms always use the latest "versions" of elements. New checks verify that this is true for both `slice::sort` and `slice::sort_unstable`.
As a side note, all of those improvements were made as part of the parallel sorts PR in Rayon (nikomatsakis/rayon#379) and now I'm backporting them into libcore/libstd.
r? @alexcrichton
When writing LLVM IR output demangled fn name in comments
`--emit=llvm-ir` looks like this now:
```
; <alloc::vec::Vec<T> as core::ops::index::IndexMut<core::ops::range::RangeFull>>::index_mut
; Function Attrs: inlinehint uwtable
define internal { i8*, i64 } @"_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E"(%"alloc::vec::Vec<u8>"* dereferenceable(24)) unnamed_addr #0 {
start:
...
```
cc https://github.com/integer32llc/rust-playground/issues/15
fixed some clippy warnings in compiletest
This is mainly readability stuff. Whenever the `clone_ref` lint asked me to clone the dereferenced object, I removed the `.clone()` instead, relying on the fact that it has worked so far and the immutable borrow ensures that the value won't change.
rustc_llvm: re-run build script when env var LLVM_CONFIG changes
This removes the changes done in #42429 and use the newly introduced `cargo:rerun-if-env-changed` in https://github.com/rust-lang/cargo/pull/4125.
As `LLVM_CONFIG` env var points to the `llvm-config` and changes when it gets configured in `config.toml` or removed from it, we can re-run the build script if this env var changes.
closes#42444
r? @alexcrichton
Document possible `io::ErrorKind`s of `fs::open`
Try to make clear that this isn't an API guarantee for now, as we likely
want to refine these errors in the future, e.g. `ENOSPC` "No space left
on device".
CC #40322
Adding diagnostic code 0611 for lifetime errors with one named, one anonymous lifetime parameter
This is a fix for #42517
Note that this only handles the above case for **function declarations** and **traits**.
`impl items` and `closures` will be handled in a later PR.
Example
```
fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32 {
if x > y { x } else { y }
}
```
now displays the following error message. ui tests have been added for the same.
```
error[E0611]: explicit lifetime required in the type of `x`
11 | fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32 {
| ^ consider changing the type of `x` to `&'a i32`
12 | if x > y { x } else { y }
| - lifetime `'a` required
```
#42516
r? @nikomatsakis
mem_categorization: handle type-based paths in variant patterns
These can't be used in correct programs, but must be handled in order to
prevent ICEs.
Fixes#42880.
r? @eddyb
Coerce fields to the expected field type
Fully fixes#31260.
This needs a crater run. I was supposed to do this last month but it slipped. Let's get this done.
Add `Iterator::for_each`
This works like a `for` loop in functional style, applying a closure to
every item in the `Iterator`. It doesn't allow `break`/`continue` like
a `for` loop, nor any other control flow outside the closure, but it may
be a more legible style for tying up the end of a long iterator chain.
This was tried before in #14911, but nobody made the case for using it
with longer iterators. There was also `Iterator::advance` at that time
which was more capable than `for_each`, but that no longer exists.
The `itertools` crate has `Itertools::foreach` with the same behavior,
but thankfully the names won't collide. The `rayon` crate also has a
`ParallelIterator::for_each` where simple `for` loops aren't possible.
> I really wish we had `for_each` on seq iterators. Having to use a
> dummy operation is annoying. - [@nikomatsakis][1]
[1]: https://github.com/nikomatsakis/rayon/pull/367#issuecomment-308455185
Rebase LLVM on top of LLVM 4.0.1
Fixes#42893.
Please don't backport this to beta as-is - I'm not sure I want rust-lang/llvm#84 to sneak to beta before it gets sufficient testing.
r? @alexcrichton
Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate.
Shift mir-dataflow from `rustc_borrowck` to `rustc_mir` crate.
Turn `elaborate_drops` and `rustc_peek` implementations into MIR passes that also live in `rustc_mir` crate.
Rewire things so `rustc_driver` uses the `ElaborateDrops` from `rustc_mir` crate.
(This PR is another baby step for mir-borrowck; it is a piece of work that other people want to rebase their stuff on top of, namely developers who are doing other dataflow analyses on top of MIR.)
I have deliberately architected this PR in an attempt to minimize the number of actual code changes. The majority of the diff should be little more than changes to mod and use declarations, as well as a few visibility promotions to pub(crate) when a declaration was moved downward in the module hierarchy.
(I have no problem with other PR's that move declarations around to try to clean this up; my goal was to ensure that the diff here was as small as possible, to make the review nearly trivial.)
Unsized tuple coercions
Part of #18469. Fixes#32702.
#37685 and #34451 might also be related.
This PR does the following:
- Introduce explicit `Sized` constraints on tuple initializers, similar to that of record-struct initializers. Not much relevant to the main contribution but I noticed this when making tests for unsized tuple coercions.
- Implement `(.., T): Unsize<(.., U)>` where `T: Unsize<U>`.
- Assume `(.., T)` is MaybeUnsizedUnivariant.
- Modify `src/librustc/ty/util.rs` and `src/librustc_trans/glue.rs` so that tuples and structs are uniformly traversed when translating.
