Use drop_guard in some places in {core,alloc,std}

[GrigorenkoPV]

• Tracking issue: Tracking Issue for core::mem::DropGuard #144426
• Will conflict with Stabilize core::mem::DropGuard #161520
• Add no-value DropGuard::new(|| ...) #161550 would also be cool occasionally

Didn't touch the places where manual impl Drops had #[inline] on their fn drop or where the guard type had other impls beside Drop and/or was named a lot.

No LLMs used, only pure human slop.

[rustbot]

r? @clarfonthey

rustbot has assigned @clarfonthey.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[clarfonthey]

The way the code was moved around makes this a bit more difficult to review, but otherwise, it looks good to me. Just a limitation of how diffs work.

I think this is a strict improvement regardless of stabilisation. I don't think this should require more than a rebase from Yosh, so, it should be fine that this conflicts with the stabilisation PR.

@bors r+ rollup

Thank you!

[rust-bors]

📌 Commit a5a9d5d has been approved by clarfonthey

It is now in the queue for this repository.

[JonathanBrouwer]

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #161715 (comment)

[rust-bors]

This pull request was unapproved.

This PR was contained in a rollup (#161715), which was unapproved.

View changes since this unapproval

[GrigorenkoPV]

@rustbot ready

[yoshuawuyts]

@GrigorenkoPV thank you for filing this PR; this is really cool to see and a very helpful reference for how DropGuard actually ends up working out in real codebases. I'm loving the 40% code reduction compared to manually creating guards for each instance. Imo it validates the usefulness of the API.

[GrigorenkoPV]

I'm loving the 40% code reduction compared to manually creating guards for each instance.

Not sure how accurate that metric is, but yeah, code reduction is definitely real.

It is especially nice to not have to write all the types out again for the struct fields. And the generics for both the struct and the Drop impl (since those cannot be reused from the outer scope; in one place the old approach even required a PhantomData just to capture one of the generic parameters, which, with this change, is not needed anymore).

Imo it validates the usefulness of the API.

Absolutely. I remember touching std (something to do with Drain or CloneUninit) at some point a few years ago and wondering why there was no "canonical" way to to scope guards.