about summary refs log tree commit diff
path: root/library/alloc
AgeCommit message (Collapse)AuthorLines
2023-01-18Update `IsZero` documentationclubby789-1/+2
2023-01-18Implement `alloc::vec::IsZero` for `Option<$NUM>` typesclubby789-0/+18
2023-01-18Rollup merge of #106950 - the8472:fix-splice-miri, r=cuviperDylan DPC-3/+9
Don't do pointer arithmetic on pointers to deallocated memory vec::Splice can invalidate the slice::Iter inside vec::Drain. So we replace them with dangling pointers which, unlike ones to deallocated memory, are allowed. Fixes miri test failures. Fixes https://github.com/rust-lang/miri/issues/2759
2023-01-18Rollup merge of #106992 - joboet:alloc_remove_box_syntax, r=thomccMatthias Krüger-1/+0
Remove unused `#![feature(box_syntax)]` in `alloc`
2023-01-18Add `vec_deque::IntoIter` benchmarksMarkus Everling-1/+145
2023-01-17Don't do pointer arithmetic on pointers to deallocated memoryThe 8472-3/+9
vec::Splice can invalidate the slice::Iter inside vec::Drain. So we replace them with dangling pointers which, unlike ones to deallocated memory, are allowed.
2023-01-17refactor[alloc]: remove unused box syntax featurejoboet-1/+0
2023-01-16Avoid unsafe code in `to_ascii_[lower/upper]case()`Chayim Refael Friedman-8/+6
2023-01-15Rebuild BinaryHeap on unwind from retainDavid Tolnay-7/+21
2023-01-15Add test showing broken behavior of BinaryHeap::retainDavid Tolnay-0/+17
2023-01-15Auto merge of #105851 - dtolnay:peekmutleak, r=Mark-Simulacrumbors-10/+75
Leak amplification for peek_mut() to ensure BinaryHeap's invariant is always met In the libs-api team's discussion around #104210, some of the team had hesitations around exposing malformed BinaryHeaps of an element type whose Ord and Drop impls are trusted, and which does not contain interior mutability. For example in the context of this kind of code: ```rust use std::collections::BinaryHeap; use std::ops::Range; use std::slice; fn main() { let slice = &mut ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']; let cut_points = BinaryHeap::from(vec![4, 2, 7]); println!("{:?}", chop(slice, cut_points)); } // This is a souped up slice::split_at_mut to split in arbitrary many places. // // usize's Ord impl is trusted, so 1 single bounds check guarantees all those // output slices are non-overlapping and in-bounds fn chop<T>(slice: &mut [T], mut cut_points: BinaryHeap<usize>) -> Vec<&mut [T]> { let mut vec = Vec::with_capacity(cut_points.len() + 1); let max = match cut_points.pop() { Some(max) => max, None => { vec.push(slice); return vec; } }; assert!(max <= slice.len()); let len = slice.len(); let ptr: *mut T = slice.as_mut_ptr(); let get_unchecked_mut = unsafe { |range: Range<usize>| &mut *slice::from_raw_parts_mut(ptr.add(range.start), range.len()) }; vec.push(get_unchecked_mut(max..len)); let mut end = max; while let Some(start) = cut_points.pop() { vec.push(get_unchecked_mut(start..end)); end = start; } vec.push(get_unchecked_mut(0..end)); vec } ``` ```console [['7', '8', '9'], ['4', '5', '6'], ['2', '3'], ['0', '1']] ``` In the current BinaryHeap API, `peek_mut()` is the only thing that makes the above function unsound. ```rust let slice = &mut ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']; let mut cut_points = BinaryHeap::from(vec![4, 2, 7]); { let mut max = cut_points.peek_mut().unwrap(); *max = 0; std::mem::forget(max); } println!("{:?}", chop(slice, cut_points)); ``` ```console [['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'], [], ['2', '3'], ['0', '1']] ``` Or worse: ```rust let slice = &mut ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']; let mut cut_points = BinaryHeap::from(vec![100, 100]); { let mut max = cut_points.peek_mut().unwrap(); *max = 0; std::mem::forget(max); } println!("{:?}", chop(slice, cut_points)); ``` ```console [['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'], [], ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '\u{1}', '\0', '?', '翾', '?', '翾', '\0', '\0', '?', '翾', '?', '翾', '?', '啿', '?', '啿', '?', '啿', '?', '啿', '?', '啿', '?', '翾', '\0', '\0', '񤬐', '啿', '\u{5}', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\u{8}', '\0', '`@',` '\0', '\u{1}', '\0', '?', '翾', '?', '翾', '?', '翾', ' thread 'main' panicked at 'index out of bounds: the len is 33 but the index is 33', library/core/src/unicode/unicode_data.rs:319:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` --- This PR makes `peek_mut()` use leak amplification (https://doc.rust-lang.org/1.66.0/nomicon/leaking.html#drain) to preserve the heap's invariant even in the situation that `PeekMut` gets leaked. I'll also follow up in the tracking issue of unstable `drain_sorted()` (#59278) and `retain()` (#71503).
2023-01-14Document guarantees about BinaryHeap invariantDavid Tolnay-1/+9
2023-01-14Leak amplification for peek_mut() to ensure BinaryHeap's invariant is always metDavid Tolnay-9/+46
2023-01-14Add test of leaking a binary_heap PeekMutDavid Tolnay-0/+20
2023-01-14Remove various double spaces in source comments.André Vennberg-14/+14
2023-01-14Use associated items of `char` instead of freestanding items in `core::char`Lukas Markeffsky-4/+4
2023-01-14Rollup merge of #106692 - eggyal:mv-binary_heap.rs-binary_heap/mod.rs, ↵Yuki Okushi-0/+0
r=Mark-Simulacrum mv binary_heap.rs binary_heap/mod.rs I confess this request is somewhat selfish, as it's made in order to ease synchronisation with my [copse](https://crates.io/crates/copse) crate (see eggyal/copse#6 for explanation). I wholly understand that such grounds may be insufficient to justify merging this request—but no harm in asking, right?
2023-01-10mv binary_heap.rs binary_heap/mod.rsAlan Egerton-0/+0
2023-01-10impl: specialize impl of `ToString` on `bool`Ezra Shaw-0/+9
2023-01-08Rollup merge of #106584 - kpreid:vec-allocator, r=JohnTitorMichael Goulet-0/+5
Document that `Vec::from_raw_parts[_in]` must be given a pointer from the correct allocator. Currently, the documentation of `Vec::from_raw_parts` and `Vec::from_raw_parts_in` says nothing about what allocator the pointer must come from. This PR adds that missing information explicitly.
2023-01-08Auto merge of #90291 - geeklint:loosen_weak_debug_bound, r=dtolnaybors-2/+2
Loosen the bound on the Debug implementation of Weak. Both `rc::Weak<T>` and `sync::Weak<T>` currently require `T: Debug` in their own `Debug` implementations, but they don't currently use it; they only ever print a fixed string. A general implementation of Debug for Weak that actually attempts to upgrade and rely on the contents is unlikely in the future because it may have unbounded recursion in the presence of reference cycles, which Weak is commonly used in. (This was the justification for why the current implementation [was implemented the way it is](https://github.com/rust-lang/rust/pull/19388/commits/f0976e2cf3f6b0027f118b791e0888b29fbb41a7)). When I brought it up [on the forum](https://internals.rust-lang.org/t/could-the-bound-on-weak-debug-be-relaxed/15504), it was suggested that, even if an implementation is specialized in the future that relies on the data stored within the Weak, it would likely rely on specialization anyway, and could therefore easily specialize on the Debug bound as well.
2023-01-08Rollup merge of #106562 - clubby789:vec-deque-example, r=Mark-SimulacrumYuki Okushi-1/+3
Clarify examples for `VecDeque::get/get_mut` Closes #106114 ``@rustbot`` label +A-docs
2023-01-08Auto merge of #104658 - thomcc:rand-update-and-usable-no_std, r=Mark-Simulacrumbors-360/+394
Update `rand` in the stdlib tests, and remove the `getrandom` feature from it. The main goal is actually removing `getrandom`, so that eventually we can allow running the stdlib test suite on tier3 targets which don't have `getrandom` support. Currently those targets can only run the subset of stdlib tests that exist in uitests, and (generally speaking), we prefer not to test libstd functionality in uitests, which came up recently in https://github.com/rust-lang/rust/pull/104095 and https://github.com/rust-lang/rust/pull/104185. Additionally, the fact that we can't update `rand`/`getrandom` means we're stuck with the old set of tier3 targets, so can't test new ones. ~~Anyway, I haven't checked that this actually does allow use on tier3 targets (I think it does not, as some work is needed in stdlib submodules) but it moves us slightly closer to this, and seems to allow at least finally updating our `rand` dep, which definitely improves the status quo.~~ Checked and works now. For the most part, our tests and benchmarks are fine using hard-coded seeds. A couple tests seem to fail with this (stuff manipulating the environment expecting no collisions, for example), or become pointless (all inputs to a function become equivalent). In these cases I've done a (gross) dance (ab)using `RandomState` and `Location::caller()` for some extra "entropy". Trying to share that code seems *way* more painful than it's worth given that the duplication is a 7-line function, even if the lines are quite gross. (Keeping in mind that sharing it would require adding `rand` as a non-dev dep to std, and exposing a type from it publicly, all of which sounds truly awful, even if done behind a perma-unstable feature). See also some previous attempts: - https://github.com/rust-lang/rust/pull/86963 (in particular https://github.com/rust-lang/rust/pull/86963#issuecomment-885438936 which explains why this is non-trivial) - https://github.com/rust-lang/rust/pull/89131 - https://github.com/rust-lang/rust/pull/96626#issuecomment-1114562857 (I tried in that PR at the same time, but settled for just removing the usage of `thread_rng()` from the benchmarks, since that was the main goal). - https://github.com/rust-lang/rust/pull/104185 - Probably more. It's very tempting of a thing to "just update". r? `@Mark-Simulacrum`
2023-01-07Document that `Vec::from_raw_parts[_in]` must be given a pointer from the ↵Kevin Reid-0/+5
correct allocator.
2023-01-07Rollup merge of #105128 - Sp00ph:vec_vec_deque_conversion, r=dtolnayMatthias Krüger-3/+3
Add O(1) `Vec -> VecDeque` conversion guarantee (See #105072)
2023-01-07Clarify examples for `VecDeque::get/get_mut`clubby789-1/+3
2023-01-04Update rand in the stdlib tests, and remove the getrandom feature from itThom Chiovoloni-360/+394
2023-01-04Auto merge of #106239 - LegionMammal978:thin-box-drop-guard, r=Amanieubors-13/+34
Deallocate ThinBox even if the value unwinds on drop This makes it match the behavior of an ordinary `Box`.
2023-01-03Rollup merge of #106045 - RalfJung:oom-nounwind-panic, r=AmanieuMichael Goulet-1/+15
default OOM handler: use non-unwinding panic, to match std handler The OOM handler in std will by default abort. This adjusts the default in liballoc to do the same, using the `can_unwind` flag on the panic info to indicate a non-unwinding panic. In practice this probably makes little difference since the liballoc default will only come into play in no-std situations where people write a custom panic handler, which most likely will not implement unwinding. But still, this seems more consistent. Cc `@rust-lang/wg-allocators,` https://github.com/rust-lang/rust/issues/66741
2023-01-02default OOM handler: use non-unwinding panic (unless -Zoom=panic is set), to ↵Ralf Jung-1/+15
match std handler
2023-01-01Deallocate ThinBox even if the value unwinds on dropLegionMammal978-13/+34
2022-12-30Rollup merge of #106248 - dtolnay:revertupcastlint, r=jackh726Michael Goulet-2/+0
Revert "Implement allow-by-default `multiple_supertrait_upcastable` lint" This is a clean revert of #105484. I confirmed that reverting that PR fixes the regression reported in #106247. ~~I can't say I understand what this code is doing, but maybe it can be re-landed with a different implementation.~~ **Edit:** https://github.com/rust-lang/rust/issues/106247#issuecomment-1367174384 has an explanation of why #105484 ends up surfacing spurious `where_clause_object_safety` errors. The implementation of `where_clause_object_safety` assumes we only check whether a trait is object safe when somebody actually uses that trait with `dyn`. However the implementation of `multiple_supertrait_upcastable` added in the problematic PR involves checking *every* trait for whether it is object-safe. FYI `@nbdd0121` `@compiler-errors`
2022-12-30Update paths in comments.jonathanCogan-1/+1
2022-12-30Replace libstd, libcore, liballoc in line comments.jonathanCogan-6/+6
2022-12-30Replace libstd, libcore, liballoc in docs.jonathanCogan-2/+2
2022-12-29Revert "Implement allow-by-default multiple_supertrait_upcastable lint"David Tolnay-2/+0
This reverts commit 5e44a65517bfcccbe6624a70b54b9f192baa94f3.
2022-12-29Implement more methods for `vec_deque::IntoIter`Markus Everling-1/+184
2022-12-28fix documenting private items of standard libraryLukas Markeffsky-11/+18
2022-12-28Update bootstrap cfgPietro Albini-45/+2
2022-12-28Rollup merge of #105484 - nbdd0121:upcast, r=compiler-errorsfee1-dead-0/+2
Implement allow-by-default `multiple_supertrait_upcastable` lint The lint detects when an object-safe trait has multiple supertraits. Enabled in libcore and liballoc as they are low-level enough that many embedded programs will use them. r? `@nikomatsakis`
2022-12-28Rollup merge of #104024 - noeddl:unused-must-use, r=compiler-errorsfee1-dead-1/+1
Fix `unused_must_use` warning for `Box::from_raw`
2022-12-28Rollup merge of #94145 - ssomers:binary_heap_tests, r=jyn514fee1-dead-60/+109
Test leaking of BinaryHeap Drain iterators Add test cases about forgetting the `BinaryHeap::Drain` iterator, and slightly fortifies some other test cases. Consists of separate commits that I don't think are relevant on their own (but I'll happily turn these into more PRs if desired).
2022-12-27Update the documentation of `Vec` to use `extend(array)` instead of ↵Chayim Refael Friedman-1/+1
`extend(array.iter().copied())`
2022-12-24add lib tests for vec::IntoIter alignment issuesRalf Jung-2/+27
2022-12-23fix one more unaligned self.ptr, and add testsRalf Jung-1/+1
2022-12-23fix IntoIter::drop on high-alignment ZSTRalf Jung-10/+11
2022-12-20Auto merge of #105127 - Sp00ph:const_new, r=dtolnaybors-3/+4
Make `VecDeque::new` const (See #105072)
2022-12-19Update coerce_unsized tracking issue from #27732 to #18598Anders Kaseorg-5/+5
Issue #27732 was closed as a duplicate of #18598. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
2022-12-17std::fmt: Use args directly in example codeEvan Jones-2/+2
The lint "clippy::uninlined_format_args" recommends inline variables in format strings. Fix two places in the docs that do not do this. I noticed this because I copy/pasted one example in to my project, then noticed this lint error. This fixes: error: variables can be used directly in the `format!` string --> src/main.rs:30:22 | 30 | let string = format!("{:.*}", decimals, magnitude); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: variables can be used directly in the `format!` string --> src/main.rs:39:2 | 39 | write!(&mut io::stdout(), "{}", args).unwrap();
2022-12-15doc: Fix a few small issuesHannes Körber-1/+1
* A few typos around generic types (`;` vs `,`) * Use inline code formatting for code fragments * One instance of wrong wording
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 04:53:47 +0000