Add A: 'static bound for Arc/Rc::pin_in

[zetanumbers]

Analogous to #79327
Needed to preserve pin's drop guarantee

[rustbot]

r? @joshtriplett

(rustbot has picked a reviewer for you, use r? to override)

[joshtriplett]

r? libs-api

[Amanieu]

@bors r+

[bors]

📌 Commit 656a388 has been approved by Amanieu

It is now in the queue for this repository.

[RalfJung]

This seems like something that needs a comment somewhere to explain these bounds -- someone just finding them in the code might be very confused about why they are needed.

[Amanieu]

@bors r-

@zetanumbers Can you add a comment explaining why this is needed? Also add it to the original Box::pin_in,

[zetanumbers]

So it's a bit tricky to argue what bounds should be on Arc::pin_in because I don't see any practical use of it (or Pin<Arc<T>> in general) right now.

So #79327 was justified because otherwise it violates pin's drop guarantee, which says that memory that holds pointee of a pinned (smart) pointer is allowed to be deallocated only after dropping the pointee, unless pointee is !Unpin. This guarantee to some extend can allow, for example, to send a pointer to a buffer allocated inside of the future's local state to write some data to it. It is also needed for hypothetical scoped async tasks and scoped thread join handles in particular to be able to safely capture references to future's local state (see proposal's zulip thread).

So why is there even Arc::pin? Arc does not implement DerefMut, so to be honest I hardly see any reasonable use case. Except for one hypothetical functionality:

/// This is kinda like `Arc::get_mut` but with `Pin`
fn pin_arc_get_mut(this: &mut Pin<Arc<T>>) -> Option<Pin<&mut T>> {
  // implementation
}

[zetanumbers]

So I say it would probably will never be less beneficial to have this bound, since Pin<Arc<T>> is useless otherwise anyway. That unless someone already deemed it reasonable to implement that pin_arc_get_mut. :)

[zetanumbers]

Actually I would like to add this Arc::get_pin_mut as a static method. I assume that would require RFC, right?

[Amanieu]

It would require an ACP, along with a real use case for it.

[Amanieu]

For this PR, I think just a simple sentence saying that Pin requires that the underlying allocation be leaked if a pinned object is leaked, which is only possible for A: 'static.

[Amanieu]

@bors r+

[bors]

📌 Commit 656a388 has been approved by Amanieu

It is now in the queue for this repository.

[bors]

⌛ Testing commit 656a388 with merge 46961d2...

[bors]

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing 46961d2 to master...

[rust-timer]

Finished benchmarking commit (46961d2): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.5%	[4.5%, 4.5%]	1
Regressions ❌ (secondary)	3.0%	[3.0%, 3.0%]	1
Improvements ✅ (primary)	-5.6%	[-5.6%, -5.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.5%	[-5.6%, 4.5%]	2

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.3%	[-1.6%, -1.0%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 676.479s -> 677.39s (0.13%)
Artifact size: 316.06 MiB -> 315.96 MiB (-0.03%)

[zetanumbers]

So why is there even Arc::pin? Arc does not implement DerefMut, so to be honest I hardly see any reasonable use case. Except for one hypothetical functionality:

/// This is kinda like `Arc::get_mut` but with `Pin`
fn pin_arc_get_mut(this: &mut Pin<Arc<T>>) -> Option<Pin<&mut T>> {
  // implementation
}

I have come to a such feature would be unsound. Actually I believe Arc::pin is practically useless since you can unpin any arc with simple Arc::clone. Thus Arc::pin should be deprecated I think. I should investigate code using it.

EDIT: After reading Pin documentation again, I've found that there's no safe way to get a reference to the smart pointer itself, so that checks out.

[RalfJung]

A comment in a closed PR is likely to be lost. It's better to open an issue or a discussion on Zulip - with more details on why the function is useless, maybe doing some code search on the web to find existing uses.