Add Drop::pin_drop for pinned drops

[frank-king]

This PR is part of the pin_ergonomics experiment (the tracking issue is #130494). It allows implementing Drop with a pinned self receiver, which is required for safe pin-projection.

Implementations:

• At least and at most one of drop and pin_drop should be implemented.
• No direct call of drop or pin_drop. They should only be called by the drop glue.
• pin_drop must and must only be used with types that support pin-projection (i.e. types with #[pin_v2]).
• Allows writing fn drop(&pin mut self) and desugars to fn pin_drop(&pin mut self). (Will be in the next PRs)

[frank-king]

The CI failed because Drop::drop becomes a provided method. I'm afraid it might not be a good way to hack into librustdoc. Is there any other good way to fix it?

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[frank-king]

@rustbot ready

[petrochenkov]

@bors try @rust-timer queue

[petrochenkov]

@bors try cancel

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/21514664349

[petrochenkov]

@bors try @rust-timer queue

[Kobzol]

FWIW, once you queue a PR once for rust-timer, it will stay queued until the first successful try build.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 5839d92 (5839d9220060a1fab73f2313dae06842f96afa2d, parent: 7d8ebe3128fc87f3da1ad64240e63ccf07b8f0bd)

[rust-timer]

Finished benchmarking commit (5839d92): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 2.1%, secondary 3.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.1%	[1.4%, 2.8%]	3
Regressions ❌ (secondary)	3.7%	[3.7%, 3.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[1.4%, 2.8%]	3

Cycles

Results (primary -2.0%, secondary 3.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.5%, 4.1%]	2
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.0%	[-2.0%, -2.0%]	1

Binary size

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

Bootstrap: 475.389s -> 476.74s (0.28%)
Artifact size: 397.80 MiB -> 397.80 MiB (0.00%)

[petrochenkov]

Now the only remaining question is where is the src/doc/book submodule pointing now.
Is it in the https://github.com/rust-lang/book repo at least? How can we be sure it won't disappear in the future?

[petrochenkov]

It should probably point to something from the main branch of the book repo to be safe.
If changing the link breaks the book's CI, then just remove the link temporarily.
@rustbot author