summary refs log tree commit diff
path: root/src/liballoc/vec.rs
AgeCommit message (Collapse)AuthorLines
2020-03-09Vec::new is const tstable in 1.39 not 1.32Christopher Durham-1/+1
2020-03-07Rollup merge of #69773 - matthiaskrgr:typos, r=petrochenkovMazdak Farrokhzad-1/+1
fix various typos
2020-03-06Don't redundantly repeat field names (clippy::redundant_field_names)Matthias Krüger-1/+1
2020-03-06fix various typosMatthias Krüger-1/+1
2020-03-01Rollup merge of #69568 - JOE1994:patch-2, r=Dylan-DPCDylan DPC-2/+3
Clarify explanation of Vec<T> 'fn resize' 1. Clarified on what should implement `Clone` trait. 2. Minor grammar fix: to be able clone => to be able **to** clone
2020-02-29clarify alignment requirements in Vec::from_raw_partsRalf Jung-1/+5
2020-02-29Remove trailing whitespaceYoungsuk Kim-1/+1
Removed trailing whitespace which caused to fail pretty-check
2020-02-29Update src/liballoc/vec.rs Youngsuk Kim-1/+1
Following suggestion from @jonas-schievink Co-Authored-By: Jonas Schievink <jonasschievink@gmail.com>
2020-02-28Clarify explanation of 'fn resize'Youngsuk Kim-2/+3
1. Clarified on what should implement 'Clone' trait. 2. Minor grammar fix: to be able clone => to be able to clone
2020-02-26Auto merge of #67290 - jonas-schievink:leak-audit, r=KodrAusbors-14/+35
Audit liballoc for leaks in `Drop` impls when user destructor panics Inspired by https://github.com/rust-lang/rust/pull/67243 and https://github.com/rust-lang/rust/pull/67235, this audits and hopefully fixes the remaining `Drop` impls in liballoc for resource leaks in the presence of panics in destructors called by the affected `Drop` impl. This does not touch `Hash{Map,Set}` since they live in hashbrown. They have similar issues though. r? @KodrAus
2020-01-31Fixed issue 68593hman523-0/+2
2020-01-28fix: typo in vec.rsPedro de Brito-1/+1
2020-01-19Update comments in `Drain`s `Drop` implJonas Schievink-3/+5
2020-01-19Fix leak in vec::IntoIter when a destructor panicsJonas Schievink-1/+3
2020-01-19Avoid leak in `vec::Drain` when item drop panicsJonas Schievink-13/+30
2020-01-11Revert "Rollup merge of #67727 - Dylan-DPC:stabilise/remove_item, ↵Lzu Tao-1/+2
r=alexcrichton" This reverts commit 4ed415b5478c74094c2859abfddb959588cd6bb1, reversing changes made to 3cce950743e8aa74a4378dfdefbbc80223a00865.
2020-01-07Rollup merge of #67929 - mgrachev:patch-1, r=jonas-schievinkYuki Okushi-1/+1
Formatting an example for method Vec.retain
2020-01-06stabilise itdylan_DPC-1/+1
2020-01-06stabilise remove_itemdylan_DPC-1/+0
2020-01-06Formatting an example for method Vec.retainGrachev Mikhail-1/+1
2020-01-05removed blank linedylan_DPC-1/+0
2020-01-04ef em ti ... :Pdylan_DPC-4/+3
2020-01-04add partial eq bound to remove_itemdylan_DPC-1/+8
2019-12-26Remove redundant link textsMatthew Kraai-2/+2
2019-12-22Format the worldMark Rousskov-123/+125
2019-12-18Propagate cfg bootstrapMark Rousskov-4/+1
2019-12-15Rollup merge of #67300 - aloucks:issue-65970, r=rkruppeMazdak Farrokhzad-1/+16
Restore original implementation of Vec::retain This PR reverts #48065, which aimed to optimize `Vec::retain` by making use of `Vec::drain_filter`. Unfortunately at that time, `drain_filter` was unsound. The soundness hole in `Vec::drain_filter` was fixed in #61224 by guaranteeing that cleanup logic runs via a nested `Drop`, even in the event of a panic. Implementing this nested drop affects codegen (apparently?) and results in slower code. Fixes #65970
2019-12-14Restore original implementation of Vec::retainAaron Loucks-1/+16
This PR reverts #48065, which aimed to optimize `Vec::retain` by making use of `Vec::drain_filter`. Unfortunately at that time, `drain_filter` was unsound. The soundness hole in `Vec::drain_filter` was fixed in #61224 by guaranteeing that cleanup logic runs via a nested `Drop`, even in the event of a panic. Implementing this nested drop affects codegen (apparently?) and results in slower code. Fixes #65970
2019-12-13Require stable/unstable annotations for the constness of all stable ↵Oliver Scherer-0/+4
functions with a `const` modifier
2019-12-09doc: Use .copied() instead of .cloned() in Vec exampleJakub Kądziołka-1/+1
2019-11-30Rollup merge of #66759 - CAD97:patch-3, r=KodrAusMazdak Farrokhzad-0/+3
impl TrustedLen for vec::Drain The iterator methods just forward to `slice::Iter`, which is `TrustedLen`. This can probably be applied to other `Drain` structs as well.
2019-11-27Rollup merge of #66798 - bwignall:typo, r=varkorTyler Mandry-1/+1
Fix spelling typos Should be non-semantic. Uses https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines to find likely typos.
2019-11-26Fix spelling typosBrian Wignall-1/+1
2019-11-25impl TrustedLen for vec::DrainChristopher Durham-0/+3
2019-11-25Fix shrink_to panic documentationChristian Duerr-0/+2
While the potential for panicking is already documented for the `Vec::shrink_to` method, it is not clearly labeled with the usual `# Panics` heading.
2019-11-16Revise the text of `vec::split_off()` per review in #65739Mahmoud Al-Qudsi-4/+3
Remove the incorrect usage of "copy" as the trait is not called.
2019-11-16Improve documentation of `Vec::split_off(...)`Mahmoud Al-Qudsi-4/+4
The previous ordering of the sentences kept switching between the return value and the value of `self` after execution, making it hard to follow. Additionally, as rendered in the browser, the period in "`Self`. `self`" was difficult to make out as being a sentence separator and not one code block.
2019-11-15Auto merge of #64432 - gnzlbg:simplify_truncate, r=alexcrichtonbors-22/+12
Make the semantics of Vec::truncate(N) consistent with slices. This commit simplifies the implementation of `Vec::truncate(N)` and makes its semantics identical to dropping the `[vec.len() - N..]` sub-slice tail of the vector, which is the same behavior as dropping a vector containing the same sub-slice. This changes two unspecified aspects of `Vec::truncate` behavior: * the drop order, from back-to-front to front-to-back, * the behavior of `Vec::truncate` on panics: if dropping one element of the tail panics, currently, `Vec::truncate` panics, but with this PR all other elements are still dropped, and if dropping a second element of the tail panics, with this PR, the program aborts. Programs can trivially observe both changes. For example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7bef575b83b06e82b3e3529e4edbcac7)): ```rust fn main() { struct Bomb(usize); impl Drop for Bomb { fn drop(&mut self) { panic!(format!("{}", self.0)); } } let mut v = vec![Bomb(0), Bomb(1)]; std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| { v.truncate(0); })); assert_eq!(v.len(), 1); std::mem::forget(v); } ``` panics printing `1` today and succeeds. With this change, it panics printing `0` first (due to the drop order change), and then aborts with a double-panic printing `1`, just like dropping the `[Bomb(0), Bomb(1)]` slice does, or dropping `vec![Bomb(0), Bomb(1)]` does. This needs to go through a crater run. r? @SimonSapin
2019-11-13Doc: Fix link to Exten in Vec::set_lenElichai Turkel-1/+1
2019-10-28Rollup merge of #65887 - lzutao:doc-vec-get, r=rkruppeMazdak Farrokhzad-2/+4
doc: mention `get(_mut)` in Vec
2019-10-28doc: mention `get(_mut)` in VecLzu Tao-2/+4
2019-10-27doc: explain why it is unsafe to construct Vec<u8> from Vec<u16>Lzu Tao-1/+5
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
2019-10-25Add {String,Vec}::into_raw_partsJake Goulding-0/+39
2019-10-25Use ManuallyDrop in examples for {Vec,String}::from_raw_partsJake Goulding-5/+5
2019-10-01Rollup merge of #64912 - lzutao:unneeded-main-doc, r=jonas-schievinkMazdak Farrokhzad-24/+20
Remove unneeded `fn main` blocks from docs ## [No whitespace diff](https://github.com/rust-lang/rust/pull/64912/files?w=1)
2019-10-01Remove unneeded `fn main` blocks from docsLzu Tao-24/+20
2019-09-30Rollup merge of #64893 - SimonSapin:vec-of-option-box, r=sfacklerTyler Mandry-0/+25
Zero-initialize `vec![None; n]` for `Option<&T>`, `Option<&mut T>` and `Option<Box<T>>`
2019-09-29Zero-initialize `vec![None; n]` for `Option<&T>`, `Option<&mut T>` and ↵Simon Sapin-0/+25
`Option<Box<T>>`
2019-09-29Fix `vec![x; n]` with null raw fat pointer zeroing the pointer metadataSimon Sapin-2/+2
https://github.com/rust-lang/rust/pull/49496 introduced specialization based on: ``` unsafe impl<T: ?Sized> IsZero for *mut T { fn is_zero(&self) -> bool { (*self).is_null() } } ``` … to call `RawVec::with_capacity_zeroed` for creating `Vec<*mut T>`, which is incorrect for fat pointers since `<*mut T>::is_null` only looks at the data component. That is, a fat pointer can be “null” without being made entirely of zero bits. This commit fixes it by removing the `?Sized` bound on this impl (and the corresponding `*const T` one). This regresses `vec![x; n]` with `x` a null raw slice of length zero, but that seems exceptionally uncommon. (Vtable pointers are never null, so raw trait objects would not take the fast path anyway. An alternative to keep the `?Sized` bound (or even generalize to `impl<U: Copy> IsZero for U`) would be to cast to `&[u8]` of length `size_of::<U>()`, but the optimizer seems not to be able to propagate alignment information and sticks with comparing one byte at a time: https://rust.godbolt.org/z/xQFkwL ---- Without the library change, the new test fails as follows: ``` ---- vec::vec_macro_repeating_null_raw_fat_pointer stdout ---- [src/liballoc/tests/vec.rs:1301] ptr_metadata(raw_dyn) = 0x00005596ef95f9a8 [src/liballoc/tests/vec.rs:1306] ptr_metadata(vec[0]) = 0x0000000000000000 thread 'vec::vec_macro_repeating_null_raw_fat_pointer' panicked at 'assertion failed: vec[0] == null_raw_dyn', src/liballoc/tests/vec.rs:1307:5 ```
2019-09-25Snap cfgs to new betaMark Rousskov-2/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 20:15:35 +0000