rust/src/liballoc, branch 1.27.2

Stabilise inclusive_range_methods

2018-05-21T13:55:25+00:00

std: Avoid `ptr::copy` if unnecessary in `vec::Drain`

2018-05-10T20:59:03+00:00

This commit is spawned out of a performance regression investigation in #50496. In tracking down this regression it turned out that the `expand_statements` function in the compiler was taking quite a long time. Further investigation showed two key properties: * The function was "fast" on glibc 2.24 and slow on glibc 2.23 * The hottest function was memmove from glibc Combined together it looked like glibc gained an optimization to the memmove function in 2.24. Ideally we don't want to rely on this optimization, so I wanted to dig further to see what was happening. The hottest part of `expand_statements` was `Drop for Drain` in the call to `splice` where we insert new statements into the original vector. This *should* be a cheap operation because we're draining and replacing iterators of the exact same length, but under the hood memmove was being called a lot, causing a slowdown on glibc 2.23. It turns out that at least one of the optimizations in glibc 2.24 was that `memmove` where the src/dst are equal becomes much faster. [This program][prog] executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24, exhibiting how glibc 2.24 is optimizing `memmove` if the src/dst are equal. And all that brings us to what this commit itself is doing. The change here is purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being copied doesn't actually need to be copied. For normal usage of just `Drain` itself this check isn't really necessary, but because `Splice` internally contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this should fix the regression seen in #50496 on glibc 2.23 and also fix the regression on Windows where `memmove` looks to not have this optimization. Note that the way `splice` was called in `expand_statements` would cause a quadratic number of elements to be copied via `memmove` which is likely why the tuple-stress benchmark showed such a severe regression. Closes #50496 [prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3

Use ManuallyDrop instead of Option in Hole implementation

2018-05-06T14:55:40+00:00

The Option is always Some until drop, where it becomes None. Make this more explicit and avoid unwraps by using ManuallyDrop. This change should be performance-neutral as LLVM already optimizes the unwraps away in the inlined code.

Auto merge of #49724 - kennytm:range-inc-start-end-methods, r=Kimundi

2018-05-01T10:10:46+00:00

Introduce RangeInclusive::{new, start, end} methods and make the fields private. cc #49022

Auto merge of #48925 - zackmdavis:fn_must_stabilize, r=nikomatsakis

2018-04-30T22:02:33+00:00

stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940) r? @nikomatsakis

Rollup merge of #50233 - mark-i-m:const_vec, r=kennytm

2018-04-30T17:18:36+00:00

Make `Vec::new` a `const fn` `RawVec::empty/_in` are a hack. They're there because `if size_of:: == 0 { !0 } else { 0 }` is not allowed in `const` yet. However, because `RawVec` is unstable, the `empty/empty_in` constructors can be removed when #49146 is done...

Make the fields of RangeInclusive private.

2018-04-30T13:01:13+00:00

Added new()/start()/end() methods to RangeInclusive. Changed the lowering of `..=` to use RangeInclusive::new().

heh, logic is hard

2018-04-29T22:27:17+00:00

use const trick

2018-04-29T22:13:49+00:00

stabilize `#[must_use]` for functions and must-use operators

2018-04-29T03:32:49+00:00

This is in the matter of RFC 1940 and tracking issue #43302.