| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
fix memory leak when vec::IntoIter panics during drop
Fixes https://github.com/rust-lang/rust/issues/69770
|
|
|
|
|
|
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
Co-Authored-By: lzutao <taolzu@gmail.com>
|
|
|
|
|
|
|
|
fix various typos
|
|
|
|
|
|
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
|
|
|
|
Removed trailing whitespace which caused to fail pretty-check
|
|
Following suggestion from @jonas-schievink
Co-Authored-By: Jonas Schievink <jonasschievink@gmail.com>
|
|
1. Clarified on what should implement 'Clone' trait.
2. Minor grammar fix:
to be able clone => to be able to clone
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
r=alexcrichton"
This reverts commit 4ed415b5478c74094c2859abfddb959588cd6bb1, reversing
changes made to 3cce950743e8aa74a4378dfdefbbc80223a00865.
|
|
Formatting an example for method Vec.retain
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
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
|
|
functions with a `const` modifier
|
|
|
|
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.
|
|
Fix spelling typos
Should be non-semantic.
Uses https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines to find likely typos.
|
|
|
|
|
|
While the potential for panicking is already documented for the
`Vec::shrink_to` method, it is not clearly labeled with the usual
`# Panics` heading.
|
|
Remove the incorrect usage of "copy" as the trait is not called.
|
|
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.
|
|
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
|
|
|