| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add `Arc::is_unique`
Adds
```rs
impl<T> Arc<T> {
pub fn is_unique(this: &Self) -> bool;
}
```
Tracking issue: #138938
ACP: https://github.com/rust-lang/libs-team/issues/560
|
|
Removing the unnecessary local variable speeds up compilation a little.
|
|
|
|
Update safety documentation for `CString::from_ptr` and `str::from_boxed_utf8_unchecked`
## PR Description
This PR addresses missing safety documentation for two APIs:
**1. alloc::ffi::CStr::from_raw**
- `Alias`: The pointer must not be aliased (accessed via other pointers) during the reconstructed CString's lifetime.
- `Owning`: Calling this function twice on the same pointer and creating two objects with overlapping lifetimes, introduces two alive owners of the same memory. This may result in a double-free.
- `Dangling`: The prior documentation required the pointer to originate from CString::into_raw, but this constraint is incomplete. A validly sourced pointer can also cause undefined behavior (UB) if it becomes dangling. A simple Poc for this situation:
```
use std::ffi::CString;
use std::os::raw::c_char;
fn create_dangling() -> *mut c_char {
let local_ptr: *mut c_char = {
let valid_data = CString::new("valid").unwrap();
valid_data.into_raw()
};
unsafe {
let _x = CString::from_raw(local_ptr);
}
local_ptr
}
fn main() {
let dangling = create_dangling();
unsafe {let _y = CString::from_raw(dangling);} // Cause UB!
}
```
**2. alloc::str::from_boxed_utf8_unchecked**
- `ValidStr`: Bytes must contain a valid UTF-8 sequence.
|
|
Stabilise `std::ffi::c_str`
This finished FCP in #112134 but never actually got a stabilisation PR. Since the FCP in #120048 recently passed to add the `os_str` module, it would be nice to also merge this too, to ensure that both get added in the next version.
Note: The added stability attributes which *somehow* were able to be omitted before (rustc bug?) were added based on the fact that they were added in 302551388b1942bb4216bb5a15d9d55cee3643a8, which ended up in 1.85.0.
Closes: https://github.com/rust-lang/rust/issues/112134
r? libs-api
|
|
|
|
in core/alloc/std only for now, and ignoring test files
Co-authored-by: Pavel Grigorenko <GrigorenkoPV@ya.ru>
|
|
Remove unnecessary clones
r? `@SparrowLii`
|
|
I found these by grepping for `&[a-z_\.]*\.clone()`, i.e. expressions
like `&a.b.clone()`, which are sometimes unnecessary clones, and also
looking at clones nearby to cases like that.
|
|
{B,C}Str: minor cleanup
(hopefully) uncontroversial bits extracted from #139994.
|
|
|
|
|
|
This is consistent with the style of `ByteString`.
|
|
Restoring what it said prior to commit 67065fe in which it was changed
incorrectly with no supporting explanation.
Closes #139835.
|
|
|
|
Correct the misspelling of "indentifier" to "identifier" in `library/alloc/src/fmt.rs`.
|
|
Bump boostrap compiler to new beta
try-job: `*msvc*`
|
|
|
|
|
|
|
|
Improve performance of `String` methods by avoiding unnecessary memcpy
for the character bytes, with added codegen check to ensure compliance.
|
|
|
|
Replace last `usize` -> `ptr` transmute in `alloc` with strict provenance API
This replaces the `usize -> ptr` transmute in `RawVecInner::new_in` with a strict provenance API (`NonNull::without_provenance`).
The API is changed to take an `Alignment` which encodes the non-null constraint needed for `Unique` and allows us to do the construction safely.
Two internal-only APIs were added to let us avoid UB-checking in this hot code: `Layout::alignment` to get the `Alignment` type directly rather than as a `usize`, and `Unique::from_non_null` to create `Unique` in const context without a transmute.
|
|
Switch some rustc_on_unimplemented uses to diagnostic::on_unimplemented
The use on the SliceIndex impl appears unreachable, there is no mention of "vector indices" in any test output and I could not get it to show up in error messages.
|
|
|
|
Implement `alloc::sync::UniqueArc`
This implements the `alloc::sync::UniqueArc` part of #112566.
|
|
Removes some unsafety and reduces the number of `usize` -> `ptr`
transmutes which might be helpful for CHERI-like targets in the future.
|
|
Encodes the safety constraint that `Unique`'s pointer must be non-zero
into the API.
|
|
|
|
|
|
|
|
|
|
|
|
This ensures that they will be correctly mangled in a future commit.
|
|
std: Mention clone-on-write mutation in Arc<T>
Fixes #138322
r? libs
|
|
document capacity for ZST as example
The main text already covers this, although it provides weaker guarantees, but I think an example in the right spot does not hurt. Fixes #80747
|
|
Fix Ptr inconsistency in {Rc,Arc}
### PR Description
This pr aims to address the problem discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Inconsistency.20in.20.7BRc.2CArc.7D's.20ptr.20requirements/with/504259637).
### Problem Clarification
As this post presents, the `{Rc, Arc}::{in/de-crement_strong_count_/in}` do not limit the layout of the memory that `ptr` points to, while internally `Rc::from_raw_in` is called directly.
UB doesn't just appear when the strong count is decremented to zero. Miri also detects the UB of `out-of-bounds pointer use` when increment strong count is called on a pointer with an incorrect layout(shown as below).
```rust
use std::rc::Rc;
#[repr(align(8))]
struct Aligned8(u64);
#[repr(align(16))]
struct Aligned16(u64);
fn main() {
let rc: Rc<Aligned8> = Rc::new(Aligned8(42));
let raw_ptr = Rc::into_raw(rc);
unsafe {
Rc::increment_strong_count(raw_ptr as *const Aligned16);
}
}
```
Miri output:
```
error: Undefined Behavior: out-of-bounds pointer use: expected a pointer to 32 bytes of memory, but got alloc954 which is only 24 bytes from the end of the allocation
```
|
|
intrinsics: remove unnecessary leading underscore from argument names
This is unnecessary since https://github.com/rust-lang/rust/pull/135840.
|
|
Add PeekMut::refresh
I'm not sure if this should go through ACP or not. BinaryHeap is not the most critical data structure in the standard library and it would be understandable if maintainer throughput is thus too limited to accept this PR without a proper design phase that ensures the required understanding of consequence over a longer time period.
This aims to improve the useability of heaps for priority-based work queues. In certain scenarios, modifications on the most relevant or critical items are performed until a condition that determines the work items have been sufficiently addressed. For instance the criticality could be a deadline that is relaxed whenever some part of a work item is completed. Such a loop will repeatedly access the most critical item and put it back in a sorted position when it is complete. Crucially, due to the ordering invariant we know that all necessary work was performed when the completed item remains the most critical. Getting this information from the heap position avoids a (potentially more costly) check on the item state itself.
A customized `drop` with boolean result would avoid up to two more comparisons performed in both the last no-op refresh and Drop code but this occurs once in each execution of the above scenario whereas refresh occurs any number of times. Also note that the comparison overhead of Drop is only taken if the element is mutably inspected to determine the end condition, i.e. not when refresh itself is the break condition.
|
|
|
|
This improves the useability of heaps for priority-based work queues. In
certain scenarios, modifications on the most relevant or critical items are
performed until a condition that determines the work items have been
sufficiently addressed. The loop will repeatedly access the most critical
item and put it back in a sorted position when it is complete. Crucially,
due to the ordering invariant we know that all work was performed when the
completed item remains the most critical. Getting this information from the
heap position avoids a (potentially more costly) check on the item state
itself.
A customized `drop` with boolean result would avoid up to two more
comparisons performed in both the last no-op refresh and Drop code but this
occurs once in each execution of the above scenario whereas refresh occurs
any number of times. Also note that the comparison overhead of Drop is only
taken if the element is mutably inspected to determine the end condition,
i.e. not when refresh itself is the break condition.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
|
|
|
|
This feature was approved for stabilization in
https://github.com/rust-lang/rust/issues/129041#issuecomment-2508940661
so this change stabilizes it.
|
|
Put the alloc unit tests in a separate alloctests package
Same rationale as https://github.com/rust-lang/rust/pull/135937. This PR has some extra complexity though as a decent amount of tests are testing internal implementation details rather than the public api. As such I opted to include the modules containing the types under test using `#[path]` into the alloctests package. This means that those modules still need `#[cfg(test)]`, but the rest of liballoc no longer need it.
|
|
|
|
For the tests that make use of internal implementation details, we
include the module to test using #[path] in alloctests now.
|
|
|
