| Age | Commit message (Collapse) | Author | Lines |
|
Closes #48994
|
|
Stabilize vec_spare_capacity
Closes #75017
|
|
Closes #75017
|
|
|
|
|
|
Switch all libraries to the 2021 edition
The fix for https://github.com/rust-lang/rust/issues/88638#issuecomment-996620107 is to simply add const-stability for these functions.
r? `@m-ou-se`
Closes #88638.
|
|
|
|
Remove pronunciation guide from Vec<T>
I performed an extremely scientific poll on twitter, and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315
|
|
Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid
~I'm not sure I understand what's going on here correctly. And I'm pretty sure this safety comment needs to be changed. I'm just referring to the same thing that `as_mut_ptr_range` does.~ (Thanks `@RalfJung` for the guidance and clearing things up)
I tried to run https://github.com/rust-lang/miri-test-libstd on alloc with -Zmiri-track-raw-pointers, and got a failure on the test `vec::test_extend_from_within`.
I minimized the test failure into this program:
```rust
#![feature(vec_split_at_spare)]
fn main() {
Vec::<i32>::with_capacity(1).split_at_spare_mut();
}
```
The problem is that the existing implementation is actually getting a pointer range where both pointers are derived from the initialized region of the Vec's allocation, but we need the second one to be valid for the region between len and capacity. (thanks Ralf for clearing this up)
|
|
|
|
|
|
In `Vec`, two doc tests are using `MaybeUninit::write` , stabilized in 1.55. This makes docs' usage of `maybe_uninit_extra` feature unnecessary.
|
|
|
|
The previous implementation used slice::as_mut_ptr_range to derive the
pointer for the spare capacity slice. This is invalid, because that
pointer is derived from the initialized region, so it does not have
provenance over the uninitialized region.
|
|
|
|
|
|
Optimize `vec::retain` performance
This simply moves the loops into the inner function which leads to better results.
```
old:
test vec::bench_retain_100000 ... bench: 203,828 ns/iter (+/- 2,101)
test vec::bench_retain_iter_100000 ... bench: 63,324 ns/iter (+/- 12,305)
test vec::bench_retain_whole_100000 ... bench: 42,989 ns/iter (+/- 291)
new:
test vec::bench_retain_100000 ... bench: 42,180 ns/iter (+/- 451)
test vec::bench_retain_iter_100000 ... bench: 65,167 ns/iter (+/- 11,971)
test vec::bench_retain_whole_100000 ... bench: 33,736 ns/iter (+/- 12,404)
```
Measured on x86_64-unknown-linux-gnu, Zen2
Fixes #91497
|
|
fixes #91772
|
|
Rollup of 11 pull requests
Successful merges:
- #91668 (Remove the match on `ErrorKind::Other`)
- #91678 (Add tests fixed by #90023)
- #91679 (Move core/stream/stream/mod.rs to core/stream/stream.rs)
- #91681 (fix typo in `intrinsics::raw_eq` docs)
- #91686 (Fix `Vec::reserve_exact` documentation)
- #91697 (Delete Utf8Lossy::from_str)
- #91706 (Add unstable book entries for parts of asm that are not being stabilized)
- #91709 (Replace iterator-based set construction by *Set::From<[T; N]>)
- #91716 (Improve x.py logging and defaults a bit more)
- #91747 (Add pierwill to .mailmap)
- #91755 (Fix since attribute for const_linked_list_new feature)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix `Vec::reserve_exact` documentation
The documentation previously said the new capacity cannot overflow `usize`, but in fact it cannot exceed `isize::MAX`.
|
|
Fix Vec::extend_from_slice docs
`other` is a slice not a vector.
|
|
replace vec::Drain drop loops with drop_in_place
The `Drain::drop` implementation came up in https://github.com/rust-lang/rust/pull/82185#issuecomment-789584796 as potentially interfering with other optimization work due its widespread use somewhere in `println!`
`@rustbot` label T-libs-impl
|
|
The documentation previously said the new capacity cannot overflow `usize`, but in fact it cannot exceed `isize::MAX`.
|
|
|
|
Signed-off-by: TennyZhuang <zty0826@gmail.com>
|
|
This simply moves the loops into the inner function which leads to better results.
```
old:
test vec::bench_retain_100000 ... bench: 203,828 ns/iter (+/- 2,101)
test vec::bench_retain_iter_100000 ... bench: 63,324 ns/iter (+/- 12,305)
test vec::bench_retain_whole_100000 ... bench: 42,989 ns/iter (+/- 291)
new:
test vec::bench_retain_100000 ... bench: 42,180 ns/iter (+/- 451)
test vec::bench_retain_iter_100000 ... bench: 65,167 ns/iter (+/- 11,971)
test vec::bench_retain_whole_100000 ... bench: 33,736 ns/iter (+/- 12,404)
```
|
|
|
|
If `Vec::push`'s capacity check fails it calls `RawVec::reserve`, which
then also does a capacity check.
This commit introduces `reserve_for_push` which skips the redundant
capacity check, for some slight compile time speed-ups.
I tried lots of minor variations on this, e.g. different inlining
attributes. This was the best one I could find.
|
|
|
|
|
|
Mention `Vec::remove` in `Vec::swap_remove`'s docs
Thought this was a nice addition.
|
|
|
|
|
|
Add #[must_use] to remaining alloc functions
I've run out of compelling reasons to group functions together across crates so I'm just going to go module-by-module. This is everything remaining from the `alloc` crate.
I ignored these because they might be used to purposefully leak memory... or other allocator shenanigans? I dunno. I'll add them if y'all tell me to.
```rust
alloc::alloc unsafe fn alloc(layout: Layout) -> *mut u8;
alloc::alloc unsafe fn alloc_zeroed(layout: Layout) -> *mut u8;
alloc::sync::Arc<T> fn into_raw(this: Self) -> *const T;
```
I don't know why clippy ignored these. I added them myself:
```rust
alloc::collections::btree_map::BTreeMap<K, V> fn range<T: ?Sized, R>(&self, range: R) -> Range<'_, K, V>;
alloc::collections::btree_set::BTreeSet<T> fn range<K: ?Sized, R>(&self, range: R) -> Range<'_, T>;
```
I added these non-mutating `mut` functions:
```rust
alloc::collections::btree_map::BTreeMap<K, V> fn range_mut<T: ?Sized, R>(&mut self, range: R) -> RangeMut<'_, K, V>;
alloc::collections::btree_map::BTreeMap<K, V> fn iter_mut(&mut self) -> IterMut<'_, K, V>;
alloc::collections::btree_map::BTreeMap<K, V> fn values_mut(&mut self) -> ValuesMut<'_, K, V>;
alloc::collections::linked_list::LinkedList<T> fn iter_mut(&mut self) -> IterMut<'_, T>;
alloc::collections::linked_list::LinkedList<T> fn cursor_front_mut(&mut self) -> CursorMut<'_, T>;
alloc::collections::linked_list::LinkedList<T> fn cursor_back_mut(&mut self) -> CursorMut<'_, T>;
alloc::collections::linked_list::LinkedList<T> fn front_mut(&mut self) -> Option<&mut T>;
alloc::collections::linked_list::LinkedList<T> fn back_mut(&mut self) -> Option<&mut T>;
alloc::collections::linked_list::CursorMut<'a, T> fn current(&mut self) -> Option<&mut T>;
alloc::collections::linked_list::CursorMut<'a, T> fn peek_next(&mut self) -> Option<&mut T>;
alloc::collections::linked_list::CursorMut<'a, T> fn peek_prev(&mut self) -> Option<&mut T>;
alloc::collections::linked_list::CursorMut<'a, T> fn front_mut(&mut self) -> Option<&mut T>;
alloc::collections::linked_list::CursorMut<'a, T> fn back_mut(&mut self) -> Option<&mut T>;
```
I moved a few existing `#[must_use]`s from functions onto the iterator types they return: `IntoIterSorted`, `IntoKeys`, `IntoValues`.
Parent issue: #89692
r? `@joshtriplett`
|
|
|
|
Avoid allocations and copying in Vec::leak
The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it, which potentially causes a reallocation and copies the vector's contents.
By avoiding the conversion to `Box`, we can instead leak the vector without any expensive operations, just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly.
**Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However, the `Vec::leak` docs explicitly forbid this, so such code is already incorrect.
[`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak
|
|
|
|
|
|
Add #[must_use] to as_type conversions
Clippy missed these:
```rust
alloc::string::String fn as_mut_str(&mut self) -> &mut str;
core::mem::NonNull<T> unsafe fn as_uninit_mut<'a>(&mut self) -> &'a MaybeUninit<T>;
str unsafe fn as_bytes_mut(&mut self) -> &mut [u8];
str fn as_mut_ptr(&mut self) -> *mut u8;
```
Parent issue: #89692
r? ````@joshtriplett````
|
|
|
|
|
|
|
|
Correctly handle supertraits for min_specialization
Supertraits of specialization markers could circumvent checks for
min_specialization. Elaborating predicates prevents this.
r? ````@nikomatsakis````
|
|
Stabilize try_reserve
Stabilization PR for the [`try_reserve` feature](https://github.com/rust-lang/rust/issues/48043#issuecomment-898040475).
|
|
implement advance_(back_)_by on more iterators
Add more efficient, non-default implementations for `feature(iter_advance_by)` (#77404) on more iterators and adapters.
This PR only contains implementations where skipping over items doesn't elide any observable side-effects such as user-provided closures or `clone()` functions. I'll put those in a separate PR.
|
|
|
|
Add truncate note to Vec::resize
A very minor addition to the `Vec::resize` documentation to point out the `truncate` method.
When I was searching for something matching `truncate` I managed to miss it, along with some colleagues. We later found it by chance. We did find `resize` however, so I was hoping to point it out in the documentation.
|
|
Add missing `# Panics` section to `Vec` method
namely `Vec::extend_from_within`
|
|
Optimize unnecessary check in Vec::retain
The function `vec::Vec::retain` only have two stages:
1. Nothing was deleted.
2. Some elements were deleted.
Here is an unnecessary check `if g.deleted_cnt > 0` in the loop, and it's difficult for compiler to optimize it. I split the loop into two stages manully and keep the code clean using const generics.
I write a special but common bench case for this optimization. I call retain on vec but keep all elements.
Before and after this optimization:
```
test vec::bench_retain_whole_100000 ... bench: 84,803 ns/iter (+/- 17,314)
```
```
test vec::bench_retain_whole_100000 ... bench: 42,638 ns/iter (+/- 16,910)
```
The result is expected, there are two `if`s before the optimization and one `if` after.
|
|
|