Use drop_guard in some places in {core,alloc,std} - #161702
Conversation
|
r? @clarfonthey rustbot has assigned @clarfonthey. Use Why was this reviewer chosen?The reviewer was selected based on:
|
b733c5d to
a5a9d5d
Compare
|
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! |
…they
Use `drop_guard` in some places in {core,alloc,std}
- Tracking issue: rust-lang#144426
- Will conflict with rust-lang#161520
- rust-lang#161550 would also be cool occasionally
Didn't touch the places where manual `impl Drop`s had `#[inline]` on their `fn drop` or where the guard type had other `impl`s beside `Drop` and/or was named a lot.
No LLMs used, only pure human slop.
Rollup of 9 pull requests Successful merges: - #160533 (dirfd dir operations (3/4)) - #161294 (add crashtests [6/N]) - #160392 (library: motor: bump moto-rt ABI ver to 17) - #161646 (interpret: fix after_local_read handling) - #160819 (Rework `div_ceil` for nonzero integers) - #161591 (run `classify-runtime-const` test for `f128`) - #161680 (renovate: add lockfile update warning) - #161702 (Use `drop_guard` in some places in {core,alloc,std}) - #161709 (Stop rustfmt deleting attributes in fn params)
|
💔 I suspect this PR failed tests as part of a rollup After fixing the problem, consider running a try job for the failed job before re-approving. Link to failure: #161715 (comment) |
|
This pull request was unapproved. This PR was contained in a rollup (#161715), which was unapproved. |
a5a9d5d to
e990441
Compare
|
@rustbot ready |
|
@GrigorenkoPV thank you for filing this PR; this is really cool to see and a very helpful reference for how |
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
Absolutely. I remember touching |
This comment has been minimized.
This comment has been minimized.
e990441 to
f6e2586
Compare
This comment has been minimized.
This comment has been minimized.
|
@bors try |
This comment has been minimized.
This comment has been minimized.
|
This pull request was unapproved. This PR was contained in a rollup (#161952), which was unapproved. |
This comment has been minimized.
This comment has been minimized.
Use `drop_guard` in some places in {core,alloc,std}
try-job: dist-various-1
|
💔 Test for 42f5bb2 failed: CI. Failed job:
|
This comment has been minimized.
This comment has been minimized.
9b2b381 to
7bf9bf0
Compare
|
@rustbot ready I've run out of funny things to say about failing rollups |
This comment has been minimized.
This comment has been minimized.
7bf9bf0 to
3546f3a
Compare
|
@bors try jobs=dist-various-1,dist-various-2,test-various |
This comment has been minimized.
This comment has been minimized.
Use `drop_guard` in some places in {core,alloc,std}
try-job: dist-various-1
try-job: dist-various-2
try-job: test-various
|
@bors try jobs=x86_64-msvc-1 |
This comment has been minimized.
This comment has been minimized.
Use `drop_guard` in some places in {core,alloc,std}
try-job: x86_64-msvc-1
|
@bors r+ rollup note="fourth time's a charm" |
Rollup of 7 pull requests Successful merges: - #160941 (Enforce safety comments on `alloc`) - #161975 (Abort instead of unwinding out of an inconsistent BTreeMap::split_off) - #157968 (Preserve ambiguous glob lint for subtrait method picks) - #161514 (rework handling of doc attributes on macro calls) - #161944 (rustdoc: Take into account edition information for keyword highlighting) - #161974 (remove rustc_never_type_options attr remnants) - #161978 (Move rustdoc ui doctests into the right testsuite) Failed merges: - #161702 (Use `drop_guard` in some places in {core,alloc,std})
View all comments
core::mem::DropGuard#144426core::mem::DropGuard#161520DropGuard::new(|| ...)#161550 would also be cool occasionallyDidn't touch the places where manual
impl Drops had#[inline]on theirfn dropor where the guard type had otherimpls besideDropand/or was named a lot.No LLMs used, only pure human slop.