BTree: remove outdated traces of coercions
The introduction of `marker::ValMut` (#75200) meant iterators no longer see mutable keys but their code still pretends it does. And settle on the majority style `Some(unsafe {…})` over `unsafe { Some(…) }`.
r? `@Mark-Simulacrum`
Initialize BTree nodes directly in the heap
We can avoid any stack-local nodes entirely by using `Box::new_uninit`, and since the nodes are mostly `MaybeUninit` fields, we only need a couple of actual writes before `assume_init`. This should help with the stack overflows in #81444, and may also improve performance in general.
r? `@Mark-Simulacrum`
cc `@ssomers`
Added tests to drain an empty vec
Discovered this kind of issue in an unrelated library.
The author copied the tests from here and AFAIK, there are no tests for this particular case.
https://github.com/LeonineKing1199/minivec/pull/19
Signed-off-by: Hanif Bin Ariffin <hanif.ariffin.4326@gmail.com>
Add docs for shared_from_slice From impls
The advantage of making these docs is mostly in pointing out that these
functions all make new allocations and copy/clone/move the source into them.
These docs are on the function, and not the `impl` block, to avoid showing
the "[+] show undocumented items" button.
CC #51430
Fix doc test for Vec::retain(), now passes clippy::eval_order_dependence
Doc test for Vec::retain() works correctly but is flagged by clippy::eval_order_dependence. Fix avoids the issue by using an iterator instead of an index.
Discovered this kind of issue in an unrelated library.
The author copied the tests from here and AFAIK, there are no tests for this particular case.
Signed-off-by: Hanif Bin Ariffin <hanif.ariffin.4326@gmail.com>
use RWlock when accessing os::env
Multiple threads modifying the current process environment is fairly uncommon. Optimize for the more common read case.
r? ````@m-ou-se````
Increment `self.index` before calling `Iterator::self.a.__iterator_ge…
…`t_unchecked` in `Zip` `TrustedRandomAccess` specialization
Otherwise if `Iterator::self.a.__iterator_get_unchecked` panics the
index would not have been incremented yet and another call to
`Iterator::next` would read from the same index again, which is not
allowed according to the API contract of `TrustedRandomAccess` for
`!Clone`.
Fixes https://github.com/rust-lang/rust/issues/81740
The advantage of making these docs is mostly in pointing out that these
functions all make new allocations and copy/clone/move the source into them.
These docs are on the function, and not the `impl` block, to avoid showing
the "[+] show undocumented items" button.
CC #51430
Only split doctest lang strings on `,`, ` `, and `\t`. Additionally, to
preserve backwards compatibility with pandoc-style langstrings, strip a
surrounding `{}`, and remove leading `.`s from each token.
Prior to this change, doctest lang strings were split on all
non-alphanumeric characters except `-` or `_`, which limited future
extensions to doctest lang string tokens, for example using `=` for
key-value tokens.
This is a breaking change, although it is not expected to be disruptive,
because lang strings using separators other than `,` and ` ` are not
very common
BTreeMap: disentangle Drop implementation from IntoIter
No longer require every `BTreeMap` to dig up its last leaf edge before dying. This speeds up the `clone_` benchmarks by 25% for normal keys and values (far less for huge values).
r? `@Mark-Simulacrum`
Optimize Vec::retain
Use `copy_non_overlapping` instead of `swap` to reduce memory writes, like what we've done in #44355 and `String::retain`.
#48065 already tried to do this optimization but it is reverted in #67300 due to bad codegen of `DrainFilter::drop`.
This PR re-implement the drop-then-move approach. I did a [benchmark](https://gist.github.com/oxalica/3360eec9376f22533fcecff02798b698) on small-no-drop, small-need-drop, large-no-drop elements with different predicate functions. It turns out that the new implementation is >20% faster in average for almost all cases. Only 2/24 cases are slower by 3% and 5%. See the link above for more detail.
I think regression in may-panic cases is due to drop-guard preventing some optimization. If it's permitted to leak elements when predicate function of element's `drop` panic, the new implementation should be almost always faster than current one.
I'm not sure if we should leak on panic, since there is indeed an issue (#52267) complains about it before.
Bump stabilization version for const int methods
These methods missed the beta cutoff. See #80962 for details.
`@rustbot` modify labels to +A-const-fn, +A-intrinsics
r? `@m-ou-se`
Make Vec::split_at_spare_mut public
This PR introduces a new method to the public API, under
`vec_split_at_spare` feature gate:
```rust
impl<T, A: Allocator> impl Vec<T, A> {
pub fn split_at_spare_mut(&mut self) -> (&mut [T], &mut [MaybeUninit<T>]);
}
```
The method returns 2 slices, one slice references the content of the vector,
and the other references the remaining spare capacity.
The method was previously implemented while adding `Vec::extend_from_within` in #79015,
and used to implement `Vec::spare_capacity_mut` (as the later is just a
subset of former one).
See also previous [discussion in `Vec::spare_capacity_mut` tracking issue](https://github.com/rust-lang/rust/issues/75017#issuecomment-770381335).
## Unresolved questions
- [ ] Should we consider changing the name? `split_at_spare_mut` doesn't seem like an intuitive name
- [ ] Should we deprecate `Vec::spare_capacity_mut`? Any usecase of `Vec::spare_capacity_mut` can be replaced with `Vec::split_at_spare_mut` (but not vise-versa)
r? `@KodrAus`
Add `Box::into_inner`.
This adds a `Box::into_inner` method to the `Box` type. <del>I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future.</del>
r? `@m-ou-se`
