Lift T: Sized bounds from some strict_provenance pointer methods

[WaffleLapkin]

This PR removes requirement for T (pointee type) to be Sized to call pointer::{addr, expose_addr, with_addr, map_addr}. These functions don't use T's size, so there is no reason for them to require this. Updated public API:

cc @Gankra, #95228
r? libs-api

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[ghost]

This should probably also change the similar methods on NonNull.

[WaffleLapkin]

@h4x5 good catch! Weirdly enough there is no NonNull::expose_addr, but I've removed the bound from all other methods.

[dtolnay]

Reassigning yaahc's reviews as she has stepped down from the review rotation.

r? rust-lang/libs-api

[Amanieu]

This was previously discussed in the original PR here. Is there any specific use case that allowing this would enable?

Alternatively, @Gankra do you have any objections to removing these bounds since you added them in the first place?

I personally can't see any harm in removing these bounds for addr and expose_addr, but doing so for with_addr and map_addr seem much more questionable since we currently have no existing API for manually modifying the address part of a fat pointer without touching the metadata.

[jedel1043]

@Amanieu The gc crate currently uses kind of a linked list of NonNull<dyn Trace> trait objects to track the managed data. Every pointer to a garbage collected object is tagged with a "root" bit to determine if a pointer is currently on the stack or not. It currently uses as usize, but this PR will enable using addr directly:

https://github.com/Manishearth/rust-gc/blob/a243a107694c636d539856495a2ac0341a616428/gc/src/lib.rs#L119-L121

However, there's no way to easily modify the address of a pointer to a dynamic object, so tagging a NonNull<dyn Trace> pointer as rooted is done using a hack:

https://github.com/Manishearth/rust-gc/blob/a243a107694c636d539856495a2ac0341a616428/gc/src/lib.rs#L1001-L1010

Having map_addr would really help in this case.

[WaffleLapkin]

@Amanieu I can't recall the exact use case, but I wanted some of these methods when working on Arc re-implementation.

but doing so for with_addr and map_addr seem much more questionable since we currently have no existing API for manually modifying the address part of a fat pointer without touching the metadata.

That is actually a shame and exposing at least some option here would be really nice (the perfect solution would be to stabilize byte_offset, but anyway...), for example offsetting a pointer to unsized values is required to fully support Arc-like structures that hold a pointer to (DataStructureMeta, T).

---

In general extending our support of un-Sized values is really valuable IMO since it's currently lacking while it could support a lot of interesting use cases (my opinion, I'm a bit obsessed with DST lol).

[Amanieu]

We already have an (unstable) API for fat pointer manipulation: #81513

I'm tending towards accepting this PR, but I'd like to hear more opinions from the libs-api team on how these APIs interact with each other.

[m-ou-se]

Discussed in the libs-api meeting. No concerns from us.

@bors r+

[bors]

📌 Commit 662f1f2 has been approved by m-ou-se

It is now in the queue for this repository.