Allow Weak::as_ptr and friends for unsized T

[CAD97]

Relaxes impl<T> Weak<T> to impl<T: ?Sized> Weak<T> for the methods rc::Weak::as_ptr, into_raw, and from_raw.

Follow-up to #73845, which did most of the impl work to make these functions work for T: ?Sized.

We still have to adjust the implementation of Weak::from_raw here, however, because I missed a use of ptr.is_null() previously. This check was necessary when into/from_raw were first implemented, as into_raw returned ptr::null() for dangling weak. However, we now just (wrapping) offset dangling weaks' pointers the same as nondangling weak, so the null check is no longer necessary (or even hit). (I can submit just 17a928f as a separate PR if desired.)

As a nice side effect, moves the fn is_dangling definition closer to Weak::new, which creates the dangling weak.

This technically stabilizes that "something like align_of_val_raw" is possible to do. However, I believe the part of the functionality required by these methods here -- specifically, getting the alignment of a pointee from a pointer where it may be dangling iff the pointee is Sized -- is uncontroversial enough to stabilize these methods without a way to implement them on stable Rust.

r? @RalfJung, who reviewed #73845.

ATTN: This changes (relaxes) the (input) generic bounds on stable fn!

[RalfJung]

I assume the plan is to do the same for Arc once we are done with review?

[CAD97]

Yes.

... Though to be completely honest, I had convinced myself (somehow) that the sync versions already supported unsized values and didn't need to be tweaked. Obviously that's not true, so I don't know why I thought that...

[RalfJung]

The code changes look good to me, but I'd like to see unit tests added that use all of the newly T: ?Sized with an actually unsized type.

[CAD97]

Translated the existing into/from raw tests to also do the same for Weak. I still cannot get the Rust test harness to cmake properly on my machine, so I'm relying on CI to get test results here.

[RalfJung]

👍 from a code perspective.

@rust-lang/libs I think this needs FCP for being an insta-stable change.

[Amanieu]

@rfcbot fcp merge

Weak::from_raw, Weak::into_raw, Weak::as_raw now support pointers to DSTs.

[dtolnay]

I think I am going to restart this with T-lang on here as well. :/

@rfcbot fcp cancel

[rfcbot]

@dtolnay proposal cancelled.

[dtolnay]

@rust-lang/libs: This makes the following usable with T: ?Sized:

• https://doc.rust-lang.org/nightly/alloc/rc/struct.Weak.html#method.as_ptr
• https://doc.rust-lang.org/nightly/alloc/rc/struct.Weak.html#method.into_raw
• https://doc.rust-lang.org/nightly/alloc/rc/struct.Weak.html#method.from_raw
• https://doc.rust-lang.org/nightly/alloc/sync/struct.Weak.html#method.as_ptr
• https://doc.rust-lang.org/nightly/alloc/sync/struct.Weak.html#method.into_raw
• https://doc.rust-lang.org/nightly/alloc/sync/struct.Weak.html#method.from_raw

@rust-lang/lang: Calling attention to the following callout in the PR description:

This technically stabilizes that "something like size_of_val_raw" is possible to do. However, I believe the part of the functionality required by these methods here -- specifically, getting the size of a pointee from a pointer where it may be dangling iff the pointee is Sized -- is uncontroversial enough to stabilize these methods without a way to implement them on stable Rust.

(From skimming the implementation I think they might have meant align_of_val_raw not size_of_val_raw, or maybe both? @CAD97 could you confirm how size_of_val_raw is involved in the implementation?)

Here is the code in question:

https://github.com/rust-lang/rust/blob/f244725afda8e124705356f40f75f15ea3af81d3/src/liballoc/rc.rs#L2121-L2137

Effectively this stabilization is committing to the following semantic being implementable internally to std:

unsafe fn align_of_val_raw<T: ?Sized>(val: *const T) -> usize {
    if T is Sized {
        mem::align_of::<T>()
    } else {
        mem::align_of_val::<T>(&*val)
    }
}

Right now we expose the same thing unstably in https://doc.rust-lang.org/nightly/std/mem/fn.align_of_val_raw.html which is tracked by #69835.

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @SimonSapin
• @cramertj
• @dtolnay
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[CAD97]

meant align_of_val_raw not size_of_val_raw

Ah, yes, only align_of_val_raw is actually needed here. I've chunked the two into the same "feature" in my head, thus the mixup 😅

[nikomatsakis]

Notably, align_of_val is already possible and stable, so the only diff here is saying that it can be done from a raw pointer and not just a reference, right? This doesn't seem like much of anything at all to me.

[nikomatsakis]

Ah, I see, the key point is that the pointee may be dangling if T: Sized (but not otherwise).

[nikomatsakis]

Removing nominated label as this was discussed in today's @rust-lang/lang meeting. No concerns were raised.

[bors]

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

@bors r-

Oops didn't notice @RalfJung requested changes.

[RalfJung]

@CAD97 I'll just use GH suggestions to change "iff" to "if" and land that.

[RalfJung]

@bors r+

[bors]

📌 Commit e27ef13 has been approved by RalfJung

[bors]

⌛ Testing commit e27ef13 with merge 738d4a7...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: RalfJung
Pushing 738d4a7 to master...

[CAD97]

Sorry I wasn't able to make the change myself; I've "just" (August... wow time is fast) started grad school and that's eating up all my time now 😅

[RalfJung]

No worries, and enjoy grad school. :)