Use pointer offset instead of deref for A/Rc::into_raw
Internals thread: https://internals.rust-lang.org/t/rc-and-internal-mutability/11463/2?u=cad97
The current implementation of (`A`)`Rc::into_raw` uses the `Deref::deref` implementation to get the pointer-to-data that is returned. This is problematic in the proposed Stacked Borrow rules, as this only gets shared provenance over the data location. (Note that the strong/weak counts are `UnsafeCell` (`Cell`/`Atomic`) so shared provenance can still mutate them, but the data itself is not.) When promoted back to a real reference counted pointer, the restored pointer can be used for mutation through `::get_mut` (if it is the only surviving reference). However, this mutates through a pointer ultimately derived from a `&T` borrow, violating the Stacked Borrow rules.
There are three known potential solutions to this issue:
- Stacked Borrows is wrong, liballoc is correct.
- Fully admit (`A`)`Rc` as an "internal mutability" type and store the data payload in an `UnsafeCell` like the strong/weak counts are. (Note: this is not needed generally since the `RcBox`/`ArcInner` is stored behind a shared `NonNull` which maintains shared write provenance as a raw pointer.)
- Adjust `into_raw` to do direct manipulation of the pointer (like `from_raw`) so that it maintains write provenance and doesn't derive the pointer from a reference.
This PR implements the third option, as recommended by @RalfJung.
Potential future work: provide `as_raw` and `clone_raw` associated functions to allow the [`&T` -> (`A`)`Rc<T>` pattern](https://internals.rust-lang.org/t/rc-and-internal-mutability/11463/2?u=cad97) to be used soundly without creating (`A`)`Rc` from references.
Simplify Clone for Box<[T]>
The bespoke `BoxBuilder` was basically a very simple `Vec`. Instead,
let's clone to a real `Vec`, with all of its specialization for the
task, then convert back to `Box<[T]>`.
prune ill-conceived BTreeMap iter_mut assertion and test its mutability
Proposal to deal with #67438 (and I'm more sure now that this is the right thing to do).
Passes testing with miri.
Remove redundant link texts
Most of these links are followed by a parenthesized expression. I think that the redundant link texts were added to prevent interpretation as an inline link. This is unnecessary since the closing square bracket and opening parenthesis are separated by whitespace.
The bespoke `BoxBuilder` was basically a very simple `Vec`. Instead,
let's clone to a real `Vec`, with all of its specialization for the
task, then convert back to `Box<[T]>`.
Stabilize `std::{rc,sync}::Weak::{weak_count, strong_count}`
* Original PR: #56696
* Tracking issue: #57977Closes: #57977
Supporting comments:
> Although these were added for testing, it is occasionally useful to have a way to probe optimistically for whether a weak pointer has become dangling, without actually taking the overhead of manipulating atomics. Are there any plans to stabilize this?
_Originally posted by @bdonlan in https://github.com/rust-lang/rust/issues/57977#issuecomment-516970921_
> Having this stabilized would help. Currently, the only way to check if a weak pointer has become dangling is to call `upgrade`, which is by far expensive.
_Originally posted by @glebpom in https://github.com/rust-lang/rust/issues/57977#issuecomment-526934709_
Not sure if stabilizing these warrants a full RFC, so throwing this out here as a start for now.
Note: per CONTRIBUTING.md, I ran the tidy checks, but they seem to be failing on unchanged files (primarily in `src/stdsimd`).
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
