Rollup of 7 pull requests
Successful merges:
- #69041 (proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`)
- #69813 (Implement BitOr and BitOrAssign for the NonZero integer types)
- #70712 (stabilize BTreeMap::remove_entry)
- #71168 (Deprecate `{Box,Rc,Arc}::into_raw_non_null`)
- #71544 (Replace filter_map().next() calls with find_map())
- #71545 (Fix comment in docstring example for Error::kind)
- #71548 (Add missing Send and Sync impls for linked list Cursor and CursorMut.)
Failed merges:
r? @ghost
* Rename Weak::as_raw to Weak::as_ptr for consistency with some other
types.
* The as_ptr for a dangling Weak pointer might return whatever garbage
(and takes that advantage to avoid a conditional).
* Don't guarantee to be able to do `Weak::from_raw(weak.as_ptr())` (even
though it'll still work fine).
Amend Rc/Arc::from_raw() docs regarding unsafety
[This](https://stackoverflow.com/questions/59671647/is-it-safe-to-clone-a-type-erased-arc-via-raw-pointer) question on SO boils down to "is it safe to `::from_raw()` a `Rc<T>`/`Arc<T>` using a dummy `T` even if `T` is never dereferenced via the new `Rc`/`Arc`?". It almost never is.
This PR amends the docs of `from_raw()` regarding this point.
The memory fences used previously in Arc implementation are not properly
understood by ThreadSanitizer as synchronization primitives. This had
unfortunate effect where running any non-trivial program compiled with
`-Z sanitizer=thread` would result in numerous false positives.
Replace acquire fences with acquire loads when using ThreadSanitizer to
address the issue.
Remove `usable_size` APIs
This removes the usable size APIs:
- remove `usable_size` (obv)
- change return type of allocating methods to include the allocated size
- remove `_excess` API
r? @Amanieu
closesrust-lang/wg-allocators#17
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.
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`).
weak-into-raw: Clarify some details in Safety
Clarify it is OK to pass a pointer that never owned a weak count (one
from Weak::new) back into it as it was created from it. Relates to
discussion in #60728.
@CAD97 Do you want to have a look at the new docs?
Clarify it is OK to pass a pointer that never owned a weak count (one
from Weak::new) back into it as it was created from it. Relates to
discussion in #60728.
Layout::pad_to_align is infallible
As per [this comment](https://github.com/rust-lang/rust/issues/55724#issuecomment-441421651) (cc @glandium).
> Per eb981a1/src/libcore/alloc.rs (L63-L65), `layout.size()` is always <= `usize::MAX - (layout.align() - 1)`.
>
> Which means:
>
> * The maximum value `layout.size()` can have is already aligned for `layout.align()` (`layout.align()` being a power of two, `usize::MAX - (layout.align() - 1)` is a multiple of `layout.align()`)
> * Incidentally, any value smaller than that maximum value will align at most to that maximum value.
>
> IOW, `pad_to_align` can not return `Err(LayoutErr)`, except for the layout not respecting its invariants, but we shouldn't care about that.
This PR makes `pad_to_align` return `Layout` directly, representing the fact that it cannot fail.
alloc: Add new_zeroed() versions like new_uninit().
MaybeUninit has both uninit() and zeroed(), it seems reasonable to have the same
surface on Box/Rc/Arc.
Needs tests.
cc #63291
Remove recommendation about idiomatic syntax for Arc::clone
I believe we should not make this recommendation. I don't want to argue that `Arc::clone` is less idiomatic than `arc.clone`, but that the choice is not clear cut and that we should not be making this kind of call in the docs.
The `.clone()` form has advantages too: it is more succinct, it is more likely to be understood by beginners, and it is more uniform with other `clone` calls, indeed with most other method calls.
Whichever approach is better, I think that this discussion belongs in a style guide or textbook, rather than the library docs. We don't talk much about idiomatic code in the docs, this place is pretty exceptional.
The recommendation is also not followed in this repo. It is hard to figure out how many calls there are of the `.clone()` form, but there are 1550 uses of `Arc` and only 65 uses of `Arc::clone`. The recommendation has existed for over two years.
The recommendation was added in https://github.com/rust-lang/rust/pull/42137, as a result of https://github.com/rust-lang/rfcs/pull/1954. However, note that that RFC was closed because it was not necessary to change the docs (the original RFC proposed a new function instead). So I don't think an RFC is necessary here (and I'm not trying to re-litigate the discussion on that RFC (which favoured `Arc::clone` as idiomatic) in any case).
cc @nical (who added the docs in the first place; sorry :-) )
r? @alexcrichton (or someone else on @rust-lang/libs )
