fix: add aliasing rules for Box
This is a new revised version for the PR [139857](https://github.com/rust-lang/rust/pull/139857), sorry for the delayed reply. I've rewritten the sentence to closely mirror the wording from `Vec::from_raw_parts`, which clearly states the transfer of ownership and its consequences. This should make the aliasing requirements much clearer.
I opted not to include a note about `mem::forget` by default to keep the documentation focused on the primary contract, similar to `Vec`.
Documenting the case of `Weak::upgrade` returning `None` when the value behind the reference is missing
Adds a clause to the documentation of `Weak` for `Arc` which was discussed in rust-lang/rust#154936.
Adds the same clause to the documentation of `Weak` for `Rc`, because the behavior is the same.
Make `convert_while_ascii` unsafe
`convert_while_ascii` assumes `convert` only returns ASCII to ensure the output remains valid UTF-8. This adds that requirement as a safety precondition.
Make Box/Rc/Arc::into_array allocator-aware (and add doctest)
Tracking issue for `alloc_slice_into_array`: https://github.com/rust-lang/rust/issues/148082
Tracking issue for `allocator_api`: https://github.com/rust-lang/rust/issues/32838
Make the `into_array` methods on `Box`, `Rc`, and `Arc` allocator-aware.
I think the allocator-aware-ness should not be observable on stable, so these should not be additionally (comment-)gated behind `feature(allocator_api)`, just like e.g. `Box::leak` and `Vec::into_boxed_slice`. The added doctests do not use `feature(allocator_api)`.
@rustbot label T-libs-api
* Extend `core::char`'s documentation of casing issues
* Fix typos
* Fix typo
Co-authored-by: GrigorenkoPV <GrigorenkoPV+github@yandex.ru>
* Document maximum 3x character expansion
This is guaranteed by Unicode.
* Fix error in `str` casing method docs
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#154460 (Deduplication: Pulled common logic out from lower_const_arg_struct)
- rust-lang/rust#154609 (Enable `#[diagnostic::on_const]` for local impls)
- rust-lang/rust#154678 (Introduce #[diagnostic::on_move] on `Rc`)
- rust-lang/rust#154902 (rustdoc: Inherit inline attributes for declarative macros)
Explicitly forget the zero remaining elements in `vec::IntoIter::fold()`.
[Original description:] ~~This seems to help LLVM notice that dropping the elements in the destructor of `IntoIter` is not necessary. In cases it doesn’t help, it should be cheap since it is just one assignment.~~
This PR adds a function to `vec::IntoIter()` which is used 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.
This is my first ever attempt at this kind of codegen micro-optimization in the standard library, so please let me know what should go into the PR or what sort of additional systematic testing might indicate this is a good or bad idea.
This annotates the `Rc` type with the diagnostic attribute
`#[diagnostic::on_move]`. Now when a moved `Rc` is borrowed,
a suggestion to clone it is made, with a label explaining why.
Promote `char::is_case_ignorable` from perma-unstable to unstable
(Take two of https://github.com/rust-lang/rust/pull/154658, which was closed when GitHub Codespaces somehow managed to squash the entire commit history of rust-lang/rust into one commit)
This function is currently used in the implementation of `str::to_lowercase()`. There is no reason to restrict it to the stdlib, though. Reimplementations of string casing for types other than `str` -> `String` shouldn't need to waste space with a duplicate copy of this table.
@rustbot label A-unicode T-libs-api
r? @Mark-Simulacrum
Edit the docs new_in() and with_capacity_in()
I have updated the documentation for new_in().
While reviewing the code, I noticed that the documentation for with_capacity_in() was also inaccurate, so I have corrected it.
Closerust-lang/rust#154452
More informative `Debug for vec::ExtractIf`
While working on rust-lang/rust#154318, I've realized that `vec::ExtractIf` actually maintains a valid prefix and a valid suffix in the underlying vector at all times with all the temporarily-invalid elements being only in the middle.
So why not make the `Debug` output more informative? I guess we could even expose something like `get_retained_mut(&mut self) -> &mut [T]` and `get_remainder_mut(&mut self) -> &mut [T]`, but that would add new backwards compatibility burden, unlike the `Debug` implementation, which (IIRC) can be changed at any time.
This annotates the `Arc` type with the diagnostic attribute
`#[diagnostic::on_move]`. Now when a moved `Arc` is borrowed,
a suggestion to clone it is made, with a label explaining why.
Remove the `compiler-builtins` feature from default because it prevents
testing via the default `cargo test` command. It made more sense as a
default when `compiler-builtins` was a dependency that some crates added
via crates.io, but is no longer needed.
The `rustc-dep-of-std` feature is also removed since it doesn't do
anything beyond what the `compiler-builtins` feature already does.
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
Lars Schumann