| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
Includes the following changes:
* Provide `abort` on AVR [1]
[1]: https://github.com/rust-lang/compiler-builtins/pull/830
|
|
{B,C}Str: minor cleanup
(hopefully) uncontroversial bits extracted from #139994.
|
|
|
|
|
|
fix incorrect type in cstr `to_string_lossy()` docs
Restoring what it said prior to commit 67065fe in which it was changed incorrectly with no supporting explanation.
Closes #139835.
|
|
This is consistent with the style of `ByteString`.
|
|
Includes the following changes:
* Replace `#[naked]` with `#[unsafe(naked)]` [1] [2]
* Replace `bl!` with `asm_sym` [3]
[1]: https://github.com/rust-lang/compiler-builtins/pull/817
[2]: https://github.com/rust-lang/compiler-builtins/pull/821
[3]: https://github.com/rust-lang/compiler-builtins/pull/820
|
|
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`.
|
|
Update `compiler-builtins` to 0.1.153
Includes the following changes:
* Avoid OOB access in `memcpy` and `memmove` [1]
* Enable intrinsics on AVR [2]
* `libm` updates to avoid using `core::arch` vector intrinsics [3]
* Re-enable `f16` on aarch64 without Neon [4]
[1]: https://github.com/rust-lang/compiler-builtins/pull/799
[2]: https://github.com/rust-lang/compiler-builtins/pull/791
[3]: https://github.com/rust-lang/compiler-builtins/pull/814
[4]: https://github.com/rust-lang/compiler-builtins/pull/809
|
|
Includes the following changes:
* Avoid OOB access in `memcpy` and `memmove` [1]
* Enable intrinsics on AVR [2]
* `libm` updates to avoid using `core::arch` vector intrinsics [3]
* Re-enable `f16` on aarch64 without Neon [4]
[1]: https://github.com/rust-lang/compiler-builtins/pull/799
[2]: https://github.com/rust-lang/compiler-builtins/pull/791
[3]: https://github.com/rust-lang/compiler-builtins/pull/814
[4]: https://github.com/rust-lang/compiler-builtins/pull/809
|
|
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.
|
|
remove remnants of const_box feature
This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch.
Closes https://github.com/rust-lang/rust/issues/92521 by removing the feature it tracks.
r? ````@oli-obk````
|
|
Includes the following changes related to unordered atomics:
* Remove element_unordered_atomic intrinsics [1]
* Remove use of `atomic_load_unordered` and undefined behaviour [2]
There are a handful of other small changes, but nothing else
user-visible.
[1]: https://github.com/rust-lang/compiler-builtins/pull/789
[2]: https://github.com/rust-lang/compiler-builtins/pull/790
|
|
|
|
|
|
|
|
|
|
|
|
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
```
|
|
Update the standard library to Rust 2024
This updates the standard library to Rust 2024. This includes the following notable changes:
- Macros are updated to use new expression fragment specifiers. This PR includes a test to illustrate the changes, primarily allowing `const {...}` expressions now.
- Some tests show a change in MIR drop order. We do not believe this will be an observable change ([see zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/268952-edition/topic/standard.20library.20migration/near/500972873)).
Fixes https://github.com/rust-lang/rust/issues/133081
|
|
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.
|
