Add doc links to `ExtractIf` of `BTree{Set,Map}` and `LinkedList`
There were links for `Hash{Set,Map}` and `Vec{,Deque}` versions, but not these three.
Also, delete impls on non-Deref types.
Pin doesn't do anything useful for non-Deref types, so PinCoerceUnsized
on such types makes no sense.
This is a breaking change, since stable code can observe the deleted
`PinCoerceUnsized` impls by uselessly coercing between such types
inside a `Pin`.
There is still some strange behavior, such as `Pin<&mut i32>` being
able to coerce to `Pin<&dyn Send>`, but not being able to coerce to
`Pin<&i32>`. However, I don't think it's possible to fix this.
Fixes https://github.com/rust-lang/rust/issues/145081
Add APIs for dealing with titlecase
ACP: https://github.com/rust-lang/libs-team/issues/354
Tracking issue: https://github.com/rust-lang/rust/issues/153892
r? libs-api
@rustbot label T-libs -T-libs-api A-unicode
~~The last commit has some insta-stable `PartialEq` impls, therefore: @rustbot label -needs-fcp
Alternatively, I could split those out into a follow-up PR.~~ (Edit: will do in follow-up)
Optimize BTreeMap::append() using CursorMut
Since [`BTreeMap::merge`](https://github.com/rust-lang/rust/pull/152418#issuecomment-3959764862) uses `CursorMut` to avoid reconstructing the map from scratch and instead inserting other `BTreeMap` at the right places or overwriting the value in self `BTreeMap` on conflict, we might as well do the same for `BTreeMap::append`. This also means that some of the code in `append.rs` can be removed; `bulk_push()` however is used by `bulk_build_from_sorted_iterator()`, which is used by the `From`/`FromIterator` trait impl on `BTreeMap`. Feels like we should rename the file or place the `bulk_push()` in an existing file.
The same additional optimization consideration that `BTreeMap::merge` has is also applied to `BTreeMap::append`.
r? @Mark-Simulacrum since Mark has seen the `BTreeMap::merge` code already (only diff is the `Ordering::Equal` case and now one of the test assertions on a panic case has the correct value now).
Add `Wake` diagnostic item for `alloc::task::Wake`
The symbol will be defined in Clippy, as Clippy will be the sole user of the diagnostic item so far.
std: make `OsString::truncate` a no-op when `len > current_len`
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.
Tracking (`os_string_truncate`): https://github.com/rust-lang/rust/issues/133262
See also: https://github.com/rust-lang/rust/pull/32977
cc: @alexcrichton, @lolbinarycat
- `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
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.
LemonJ