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
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
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
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.
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
