| Age | Commit message (Collapse) | Author | Lines |
|---|
|
io::Write::write_fmt: panic if the formatter fails when the stream does not fail
Follow-up to https://github.com/rust-lang/rust/pull/124954
|
|
Relax allocator requirements on some Rc/Arc APIs.
Split out from #119761
* Remove `A: Clone` bound from `Rc::assume_init`(s), `Rc::downcast`, and `Rc::downcast_unchecked` (`Arc` methods were already relaxed by #120445)
* Make `From<Rc<[T; N]>> for Rc<[T]>` allocator-aware (`Arc`'s already is).
* Remove `A: Clone` from `Rc/Arc::unwrap_or_clone`
Internal changes:
* Made `Arc::internal_into_inner_with_allocator` method into `Arc::into_inner_with_allocator` associated fn.
* Add private `Rc::into_inner_with_allocator` (to match Arc), so other fns don't have to juggle `ManuallyDrop`.
|
|
|
|
|
|
* Remove A: Clone bound from Rc::assume_init, Rc::downcast, and Rc::downcast_unchecked.
* Make From<Rc<[T; N]>> for Rc<[T]> allocator-aware.
Internal changes:
* Made Arc::internal_into_inner_with_allocator method into Arc::into_inner_with_allocator associated fn.
* Add private Rc::into_inner_with_allocator (to match Arc), so other fns don't have to juggle ManuallyDrop.
|
|
allow unsized T.
|
|
Documentation of these properties previously existed in a lone paragraph
in the `fmt` module's documentation:
<https://doc.rust-lang.org/1.78.0/std/fmt/index.html#formatting-traits>
However, users looking to implement a formatting trait won't necessarily
look there. Therefore, let's add the critical information (that
formatting per se is infallible) to all the involved items.
|
|
|
|
This way, no other test can be tripped up by `test_shrink_to_unwind` changing the alloc error hook.
|
|
Luckily it's comparatively simple to just restore the `VecDeque` into a valid state on unwinds.
|
|
Box<[T]> implements FromIterator<T> using Vec<T> + into_boxed_slice().
Add analogous FromIterator implementations for Box<str>
matching the current implementations for String.
Remove the Global allocator requirement for FromIterator<Box<str>> too.
|
|
Stabilize exclusive_range_pattern (v2)
This PR is identical to #124459, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F).
r? ghost
Original PR description:
---
Stabilization report: https://github.com/rust-lang/rust/issues/37854#issuecomment-1842398130
FCP: https://github.com/rust-lang/rust/issues/37854#issuecomment-1872520294
Stabilization was blocked by a lint that was merged here: #118879
Documentation PR is here: rust-lang/reference#1484
`@rustbot` label +F-exclusive_range_pattern +T-lang
|
|
Describe and use CStr literals in CStr and CString docs
Mention CStr literals in the description of both types, and use them in some of the code samples for CStr. This is intended to make C string literals more discoverable.
Additionally, I don't think the orange "This example is not tested" warnings are very encouraging, so I have made the examples on `CStr` build.
|
|
String.truncate comment microfix (greater or equal)
String.truncate calls Vec.truncate, in turn, and that states "is greater or equal to". Beside common sense.
|
|
deref patterns: impl `DerefPure` for more std types
Context: [deref patterns](https://github.com/rust-lang/rust/issues/87121). The requirements of `DerefPure` aren't precise yet, but these types unambiguously satisfy them.
Interestingly, a hypothetical `impl DerefMut for Cow` that does a `Clone` would *not* be eligible for `DerefPure` if we allow mixing deref patterns with normal patterns. If the following is exhaustive then the `DerefMut` would cause UB:
```rust
match &mut Cow::Borrowed(&()) {
Cow::Owned(_) => ..., // Doesn't match
deref!(_x) if false => ..., // Causes the variant to switch to `Owned`
Cow::Borrowed(_) => ..., // Doesn't match
// We reach unreachable
}
```
|
|
|
|
|
|
|
|
|
|
Fully stabilize the following API, including const where applicable:
impl <T> NonNull<T> {
pub const unsafe fn offset(self, count: isize) -> Self;
pub const unsafe fn add(self, count: usize) -> Self;
pub const unsafe fn sub(self, count: usize) -> Self;
pub const unsafe fn offset_from(self, origin: NonNull<T>) -> isize;
pub const unsafe fn read(self) -> T;
pub unsafe fn read_volatile(self) -> T;
pub const unsafe fn read_unaligned(self) -> T;
pub unsafe fn write_volatile(self, val: T);
pub unsafe fn replace(self, src: T) -> T;
}
impl<T: ?Sized> NonNull<T> {
pub const unsafe fn byte_offset(self, count: isize) -> Self;
pub const unsafe fn byte_add(self, count: usize) -> Self;
pub const unsafe fn byte_sub(self, count: usize) -> Self;
pub const unsafe fn byte_offset_from<U: ?Sized>(self, origin: NonNull<U>) -> isize;
pub unsafe fn drop_in_place(self);
}
Stabilize the following without const:
impl <T> NonNull<T> {
// const under `const_intrinsic_copy`
pub const unsafe fn copy_to(self, dest: NonNull<T>, count: usize);
pub const unsafe fn copy_to_nonoverlapping(self, dest: NonNull<T>, count: usize);
pub const unsafe fn copy_from(self, src: NonNull<T>, count: usize);
pub const unsafe fn copy_from_nonoverlapping(self, src: NonNull<T>, count: usize);
// const under `const_ptr_write`
pub const unsafe fn write(self, val: T);
pub const unsafe fn write_bytes(self, val: u8, count: usize);
pub const unsafe fn write_unaligned(self, val: T);
// const under `const_swap`
pub const unsafe fn swap(self, with: NonNull<T>);
// const under `const_align_offset`
pub const fn align_offset(self, align: usize) -> usize;
// const under `const_pointer_is_aligned`
pub const fn is_aligned(self) -> bool;
}
Left the following unstable:
impl <T> NonNull<T> {
// moved gate to `ptr_sub_ptr`
pub const unsafe fn sub_ptr(self, subtracted: NonNull<T>) -> usize;
}
impl <T: ?Sized> NonNull<T> {
// moved gate to `pointer_is_aligned_to`
pub const fn is_aligned_to(self, align: usize) -> bool;
}
Fixes: https://github.com/rust-lang/rust/issues/117691
|
|
|
|
"is greater or equal to". Beside common sense.
|
|
Relax `A: Clone` bound for `rc::Weak::into_raw_and_alloc`
Makes this method to behave the same way as [`Box::into_raw_with_allocator`](https://doc.rust-lang.org/1.77.2/alloc/boxed/struct.Box.html#method.into_raw_with_allocator) and [`Vec::into_raw_parts_with_alloc`](https://doc.rust-lang.org/1.77.2/alloc/vec/struct.Vec.html#method.into_raw_parts_with_alloc).
I have also noticed the inconsistent presence and naming, should probably be addressed in the future.
|
|
|
|
Stabilize `Utf8Chunks`
Pending FCP in https://github.com/rust-lang/rust/issues/99543.
This PR includes the proposed modification in https://github.com/rust-lang/libs-team/issues/190 as agreed in https://github.com/rust-lang/rust/issues/99543#issuecomment-2050406568.
|
|
|
|
|
|
|
|
|
|
This saves an extra load from memory.
|
|
Document overrides of `clone_from()` in core/std
As mentioned in https://github.com/rust-lang/rust/pull/96979#discussion_r1379502413
Specifically, when an override doesn't just forward to an inner type, document the behavior and that it's preferred over simply assigning a clone of source. Also, change instances where the second parameter is "other" to "source".
I reused some of the wording over and over for similar impls, but I'm not sure that the wording is actually *good*. Would appreciate feedback about that.
Also, now some of these seem to provide pretty specific guarantees about behavior (e.g. will reuse the exact same allocation iff the len is the same), but I was basing it off of the docs for [`Box::clone_from`](https://doc.rust-lang.org/1.75.0/std/boxed/struct.Box.html#method.clone_from-1) - I'm not sure if providing those strong guarantees is actually good or not.
|
|
|
|
|
|
|
|
Add the following methods, that work similarly to VecDeque::as_slices:
- alloc::collections::vec_deque::Iter::as_slices
- alloc::collections::vec_deque::IterMut::into_slices
- alloc::collections::vec_deque::IterMut::as_slices
- alloc::collections::vec_deque::IterMut::as_mut_slices
Obtaining slices from a VecDeque iterator was not previously possible.
|
|
Stabilize (const_)slice_ptr_len and (const_)slice_ptr_is_empty_nonnull
Stabilized API:
```rust
impl<T> *mut [T] {
pub const fn len(self) -> usize;
pub const fn is_empty(self) -> bool;
}
impl<T> *const [T] {
pub const fn len(self) -> usize;
pub const fn is_empty(self) -> bool;
}
impl<T> NonNull<[T]> {
pub const fn is_empty(self) -> bool;
}
```
FCP completed in tracking issue: https://github.com/rust-lang/rust/issues/71146
|
|
Avoid more NonNull-raw-NonNull roundtrips in Vec
r? the8472
The standard library in general has a lot of these round-trips from niched types to their raw innards and back. Such round-trips have overhead in debug builds since https://github.com/rust-lang/rust/pull/120594. I removed some such round-trips in that initial PR and I've been meaning to come back and hunt down more such examples (this is the last item on https://github.com/rust-lang/rust/issues/120848).
|
|
|
|
|
|
Add `A: 'static` bound for `Arc/Rc::pin_in`
Analogous to https://github.com/rust-lang/rust/pull/79327
Needed to preserve pin's [drop guarantee](https://doc.rust-lang.org/std/pin/index.html#drop-guarantee)
|
|
Do not allocate for ZST ThinBox (attempt 2 using const_allocate)
There's PR https://github.com/rust-lang/rust/pull/123184 which avoids allocation for ZST ThinBox.
That PR has an issue with unsoundness with padding in `MaybeUninit` (see comments in that PR). Also that PR relies on `Freeze` trait.
This PR is much simpler implementation which does not have this problem, but it uses `const_allocate` feature.
`@oli-obk` suggested that `const_allocate` should not be used for that feature. But I like how easy it to do this feature with `const_allocate`. Maybe it's OK to use `const_allocate` while `ThinBox` is unstable? Or, well, we can abandon this PR.
r? `@oli-obk`
|
|
Similar to #114370 for VecDeque instead of Vec. It now uses `core::hint::assert_unchecked`.
|
|
|
|
|
|
There's PR https://github.com/rust-lang/rust/pull/123184
which avoids allocation for ZST ThinBox.
That PR has an issue with unsoundness with misuse of `MaybeUninit`
(see comments in that PR).
This PR is much simpler implementation which does not have this
problem, but it uses `const_allocate` feature.
|
|
Support running library tests in Miri
This adds a new bootstrap subcommand `./x.py miri` which can test libraries in Miri. This is in preparation for eventually doing that as part of bors CI, but this PR only adds the infrastructure, and doesn't enable it yet.
`@rust-lang/bootstrap` should this be `x.py test --miri library/core` or `x.py miri library/core`? The flag has the advantage that we don't have to copy all the arguments from `Subcommand::Test`. It has the disadvantage that most test steps just ignore `--miri` and still run tests the regular way. For clippy you went the route of making it a separate subcommand. ~~I went with a flag now as that seemed easier, but I can change this.~~ I made it a new subcommand. Note however that the regular cargo invocation would be `cargo miri test ...`, so `x.py` is still going to be different in that the `test` is omitted. That said, we could also make it `./x.py miri-test` to make that difference smaller -- that's in fact more consistent with the internal name of the command when bootstrap invokes cargo.
`@rust-lang/libs` ~~unfortunately this PR does some unholy things to the `lib.rs` files of our library crates.~~
`@m-ou-se` found a way that entirely avoids library-level hacks, except for some new small `lib.miri.rs` files that hopefully you will never have to touch. There's a new hack in cargo-miri but there it is in good company...
|
|
|
|
|
|
improve example on inserting to a sorted vector to avoid shifting equal elements
|
|
Just a tiny addition.
Helps with #123263.
|
