- `From<T> for ThinBox<T>`
- `From<T> for UniqueRc<T>`
- `From<T> for UniqueArc<T>`
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
Add missing safety doc for CString::from_vec_unchecked and async_drop_in_place
Add missing safety documentation for two unsafe APIs:
* `CString::from_vec_unchecked` – # Safety: the caller must ensure `v` contains no NUL bytes in its contents.
* `async_drop_in_place` – # Safety: see [`ptr::drop_in_place`] for safety requirements.
fixed VecDeque::splice() not filling the buffer correctly when resizing the buffer on start = end range
This PR fixesrust-lang/rust#151758. The issue came from `Splice::move_tail`, which as joboet pointed out:
> The issue is in move_tail, which resizes the buffer, but fails to account for the resulting hole.
The problem with reserving more space through `VecDeque`'s `buf.reserve()` is that it doesn't update `VecDeque`'s `head`, which means that this code in `move_tail`:
```rust
deque.wrap_copy(
deque.to_physical_idx(tail_start),
deque.to_physical_idx(new_tail_start),
self.tail_len,
);
```
could move over the section of data that `tail_start..tail_start + self.tail_len` of the buffer is supposed to be held at to the incorrect destination since all `.to_physical_idx()` is doing is a wrapping add on the `VecDeque`'s head with the passed in `idx` value.
To avoid this I decided to use `VecDeque::reserve` to both allocate more space into the `VecDeque` if necessary and update head appropriately. However, `VecDeque::reserve` internally relies on the `VecDeque`'s `len` field. Earlier in `VecDeque::splice`, it modifies the `VecDeque`'s `len` constructing the drain via `Drain::new` (as it does a `mem::replace` on `deque.len` with the start bound of the passed in `range`). The `VecDeque`'s `len` can also be potentially modified in the earlier `Splice::fill()` call if it does any replacement towards elements within the passed in `range` value for `VecDeque::splice()`. I needed to temporarily restore the `VecDeque`'s `len` to its actual len, so that `VecDeque::reserve` can work properly. Afterward, you can bring back the `VecDeque`'s `len` to what its value was before and fill the gap appropriately with the rest of the `replace_with` content.
r? @joboet
Adds internal `vec::IntoIter::forget_remaining_elements_and_dealloc()`,
which is used by `fold()` and `spec_extend()`, when those operations
complete, to forget the zero remaining elements and only deallocate the
allocation, ensuring that there will never be a useless loop to drop
zero remaining elements when the iterator is dropped.
Align `OsString::truncate` (and the underlying WTF-8 implementation) with `String::truncate` by making it a no-op when `len > self.len()`.
Previously, `OsString::truncate` would panic if `len > self.len()`, while `String::truncate` treats such cases as a no-op.
`BTreeMap::merge` optimized
This is an optimized version of https://github.com/rust-lang/rust/pull/151981. See [ACP](https://github.com/rust-lang/libs-team/issues/739#issuecomment-3873487320) for more information on `BTreeMap::merge` does.
CC @programmerjake. Let me know what you think of how I'm using `CursorMut` and `IntoIter` here and whether the unsafe code here looks good. I decided to use `ptr::read()` and `ptr::write()` to grab the value from `CursorMut` as `V` than `&mut V`, use it within the `conflict` function, and overwrite the content of conflicting key afterward.
I know this needs some polishing, especially with refactoring some redundant looking code in a nicer way, some of which could probably just be public API methods for `CursorMut`. It does pass all the tests that I currently have for `BTreeMap::merge` (inspired from `BTreeMap::append`) though, so that's good.
Add try_shrink_to and try_shrink_to_fit to Vec
Adds the functions `try_shrink_to` and `try_shrink_to_fit` to Vec to allow shrinking
in environments without global OOM handling.
The implementation differs from the tracking issue as the fallible methods return
a `TryReserveError` instead of an `AllocError` as `AllocError` is unstable and does
not contain layout information.
Tracking:
- rust-lang/rust#152350
* Add try_shrink_to and try_shrink_to_fit to Vec
Both functions are required to support shrinking a vector in
environments without global OOM handling.
* Format the try_shrink functions
* Remove excess "```" from doc
* Remove `cfg(not(no_global_oom_handling))` from rawvecinner::shrink
* Fix import cmp even if no_global_oom_handling is defined
Simplify internals of `{Rc,Arc}::default`
This commit simplifies the internal implementation of `Default` for these two pointer types to have the same performance characteristics as before (a side effect of changes in rust-lang/rust#131460) while avoid use of internal private APIs of Rc/Arc. To preserve the same codegen as before some non-generic functions needed to be tagged as `#[inline]` as well, but otherwise the same IR is produced before/after this change.
The motivation of this commit is I was studying up on the state of initialization of `Arc` and `Rc` and figured it'd be nicer to reduce the use of internal APIs and instead use public stable APIs where possible, even in the implementation itself.
We have a constant for it already (used in `RawVec` for basically the same polymorphization) so let's use it.
Conveniently, it can even be safe that way!
Pass alignments through the shim as `Alignment` (not `usize`)
We're using `Layout` on both sides, so might as well skip the transmutes back and forth to `usize`.
The mir-opt test shows that doing so allows simplifying the boxed-slice drop slightly, for example.
This commit simplifies the internal implementation of `Default` for
these two pointer types to have the same performance characteristics as
before (a side effect of changes in 131460) while avoid use of internal
private APIs of Rc/Arc. To preserve the same codegen as before some
non-generic functions needed to be tagged as `#[inline]` as well, but
otherwise the same IR is produced before/after this change.
The motivation of this commit is I was studying up on the state of
initialization of `Arc` and `Rc` and figured it'd be nicer to reduce the
use of internal APIs and instead use public stable APIs where possible,
even in the implementation itself.
We're using `Layout` on both sides, so might as well skip the transmutes back and forth to `usize`.
The mir-opt test shows that doing so allows simplifying the boxed-slice drop slightly, for example.
Jules Bertholet