Rollup of 6 pull requests by jhpratt · Pull Request #164179 · rust-lang/rust

jhpratt · 2026-10-11T22:18:11Z

Successful merges:

bootstrap: always build llvm's dylib when linking to it #160597 (bootstrap: always build llvm's dylib when linking to it)
vectorized vec::dedup pre-scan #162810 (vectorized vec::dedup pre-scan)
directly deallocates the nodes instead of traversing every element when BTreemap dropping #162931 (directly deallocates the nodes instead of traversing every element when BTreemap dropping)
std: add fs::rename_noreplace #162027 (std: add fs::rename_noreplace)
Nuke Unique (and ptr_internals) #164146 (Nuke Unique (and ptr_internals))
std: add doctest to parent_id #164151 (std: add doctest to parent_id)

Unlike `fs::rename`, the destination is never overwritten, returning `ErrorKind::AlreadyExists` if `to` already exists. Platform-specific APIs used: `renameat2` with `RENAME_NOREPLACE` flag on `Linux` and `Android`, `renamex_np` with `RENAME_EXCL` on `Apple`, and `MoveFileExW` without the `MOVEFILE_REPLACE_EXISTING` flag on `Windows`. On other Unix platforms, and on Linux, Android and Apple when the kernel or the filesystem doesn't support it, `link` followed by `unlink` is used instead. Platforms with neither return `Unsupported`.

Co-authored-by: Josh Triplett <josh@joshtriplett.org>

windows-bindgen no longer generates the `MOVE_FILE_FLAGS` alias, so `u32` is used instead.

`test_rename_noreplace_directory()` fails on kernels before Linux 3.15, because they lack `renameat2`, so std implementation falls back to `link`/`unlink`, which couldn't move directories, so expectations of the test were wrong. Test now accepts `PermissionDenied` on Unix, in fallback case.

…Map dropping

The bootstrap example says that LLVM's dynamic library will be built when llvm.link-shared is true. It actually only set the flag that enables linking against the library (LLVM_LINK_LLVM_DYLIB). It should also set LLVM_BUILD_LLVM_DYLIB. On clean builds, LLVM's configuration helpfully sets the BUILD flag to true if the LINK flag is true. If a dev toggles link-shared from false to true after an initial build, LINK will be "ON" (given by bootstrap) and BUILD will be "OFF" (from the cmake cache). The library to link will not be built, causing the build to fail at link time. With this change, the library is always built when it's to be linked. Conversely, it is not built if it is not to be linked.

…d, r=clubby789 bootstrap: always build llvm's dylib when linking to it The bootstrap example says that LLVM's dynamic library will be built when llvm.link-shared is true. It actually only set the flag that enables linking against the library (LLVM_LINK_LLVM_DYLIB). It should also set LLVM_BUILD_LLVM_DYLIB. On clean builds, LLVM's configuration helpfully sets the BUILD flag to true if the LINK flag is true. If a dev toggles link-shared from false to true after an initial build, LINK will be "ON" (given by bootstrap) and BUILD will be "OFF" (from the cmake cache). The library to link will not be built, causing the build to fail at link time. With this change, the library is always built when it's to be linked. Conversely, it is not built if it is not to be linked.

vectorized vec::dedup pre-scan This PR vectorizes the process of pre-scaning during `Vec::dedup`. on aarch64: bench | baseline | final | | ±Δ -- | -- | -- | -- | -- all_100 | 56 | 60 | 3 | +6.2% all_1000 | 507 | 508 | 4 | +0.2% all_10000 | 4,961 | 4,961 | 26 | +0.0% all_100000 | 48,876 | 49,179 | 204 | +0.6% none_100 | 49 | 17 | 1 | -65.5% none_1000 | 495 | 129 | 2 | -74.0% none_10000 | 4,873 | 1,226 | 7 | -74.8% none_100000 | 48,673 | 12,549 | 97 | -74.2% random_100 | 81 | 74 | 1 | -8.7% random_1000 | 692 | 610 | 3 | -11.8% random_10000 | 7,887 | 7,187 | 101 | -8.9% random_100000 | 385,167 | 363,078 | 3,987 | -5.7% slice_truncate_100 | 92 | 91 | 2 | -0.6% slice_truncate_1000 | 712 | 710 | 3 | -0.2% slice_truncate_10000 | 9,151 | 9,130 | 53 | -0.2% slice_truncate_100000 | 398,559 | 388,269 | 1,127 | -2.6% string_long_all_100 | 7,585 | 7,638 | 49 | +0.7% string_long_all_1000 | 335,862 | 326,630 | 7,669 | -2.7% string_long_all_10000 | 4,351,640 | 4,356,293 | 26,004 | +0.1% string_long_none_100 | 2,954 | 2,912 | 34 | -1.4% string_long_none_1000 | 30,945 | 29,910 | 512 | -3.3% string_long_none_10000 | 310,118 | 304,530 | 2,447 | -1.8% string_long_random_100 | 5,924 | 5,906 | 33 | -0.3% string_long_random_1000 | 119,938 | 117,517 | 1,163 | -2.0% string_long_random_10000 | 1,560,353 | 1,583,948 | 16,559 | +1.5% string_medium_all_100 | 2,532 | 2,535 | 36 | +0.1% string_medium_all_1000 | 26,413 | 26,436 | 233 | +0.1% string_medium_all_10000 | 271,453 | 268,422 | 2,226 | -1.1% string_medium_none_100 | 400 | 393 | 6 | -1.9% string_medium_none_1000 | 4,074 | 3,918 | 34 | -3.8% string_medium_none_10000 | 41,120 | 39,650 | 553 | -3.6% string_medium_random_100 | 1,155 | 1,168 | 38 | +1.1% string_medium_random_1000 | 27,462 | 27,281 | 133 | -0.7% string_medium_random_10000 | 165,098 | 164,762 | 3,789 | -0.2% string_short_all_100 | 2,353 | 2,372 | 38 | +0.8% string_short_all_1000 | 23,455 | 23,766 | 233 | +1.3% string_short_all_10000 | 235,946 | 236,944 | 3,684 | +0.4% string_short_none_100 | 281 | 268 | 5 | -4.6% string_short_none_1000 | 2,767 | 2,603 | 21 | -6.0% string_short_none_10000 | 27,633 | 25,911 | 250 | -6.2% string_short_random_100 | 1,072 | 1,079 | 15 | +0.6% string_short_random_1000 | 24,270 | 24,180 | 59 | -0.4% string_short_random_10000 | 100,799 | 98,519 | 594 | -2.3% u8_all_1000 | 464 | 463 | 3 | -0.2% u8_all_10000 | 4,479 | 4,477 | 38 | -0.0% u8_none_1000 | 469 | 87 | 2 | -81.5% u8_none_10000 | 4,611 | 811 | 7 | -82.4% u8_random_1000 | 568 | 567 | 11 | -0.2% u8_random_10000 | 4,583 | 4,578 | 36 | -0.1% wide_all_1000 | 1,849 | 1,854 | 20 | +0.3% wide_all_10000 | 18,499 | 18,446 | 176 | -0.3% wide_none_1000 | 1,081 | 909 | 1 | -15.9% wide_none_10000 | 10,395 | 9,289 | 122 | -10.6% wide_random_1000 | 1,805 | 1,796 | 6 | -0.5% wide_random_10000 | 17,994 | 17,984 | 82 | -0.1%

@Amanieu

directly deallocates the nodes instead of traversing every element when BTreemap dropping When BTreeMap is dropping, it currently turns the tree into an iterator and traverses the kvs, updating the LazyLeafRange after each element is dropped. This is unnecessary during destruction. We can instead traverse the tree node by node and drop the kvs directly from each node. Results on aarch64: - btree::map benchmark | baseline | without drop | change | with drop | change | pp diff (with − without) -- | -- | -- | -- | -- | -- | -- clone_fat_val_100 | 10849.14 | 7433.38 | -31.5% | 7573.66 | -30.2% | +1.3pp clone_fat_val_100_and_clear | 11021.05 | 7606.91 | -31.0% | 7769.49 | -29.5% | +1.5pp clone_fat_val_100_and_drain_all | 57652.20 | 55026.07 | -4.6% | 55495.20 | -3.7% | +0.8pp clone_fat_val_100_and_drain_half | 27258.25 | 23993.80 | -12.0% | 24005.43 | -11.9% | +0.0pp clone_fat_val_100_and_into_iter | 15149.81 | 12289.52 | -18.9% | 12401.29 | -18.1% | +0.7pp clone_fat_val_100_and_pop_all | 56717.62 | 54045.12 | -4.7% | 54643.59 | -3.7% | +1.1pp clone_fat_val_100_and_remove_all | 64333.00 | 61907.57 | -3.8% | 62039.79 | -3.6% | +0.2pp clone_fat_val_100_and_remove_half | 28440.43 | 25290.79 | -11.1% | 25634.00 | -9.9% | +1.2pp clone_slim_100 | 1978.26 | 687.38 | -65.3% | 798.38 | -59.6% | +5.6pp clone_slim_100_and_clear | 1908.35 | 687.58 | -64.0% | 796.25 | -58.3% | +5.7pp clone_slim_100_and_drain_all | 3983.43 | 4244.24 | +6.5% | 4123.55 | +3.5% | -3.0pp clone_slim_100_and_drain_half | 4241.43 | 3551.33 | -16.3% | 3624.14 | -14.6% | +1.7pp clone_slim_100_and_into_iter | 1805.39 | 1753.37 | -2.9% | 1840.42 | +1.9% | +4.8pp clone_slim_100_and_pop_all | 3243.54 | 3247.17 | +0.1% | 3321.00 | +2.4% | +2.3pp clone_slim_100_and_remove_all | 5203.97 | 5176.58 | -0.5% | 5282.19 | +1.5% | +2.0pp clone_slim_100_and_remove_half | 2399.04 | 1818.85 | -24.2% | 1929.16 | -19.6% | +4.6pp clone_slim_10k | 205051.50 | 74942.50 | -63.5% | 83515.00 | -59.3% | +4.2pp clone_slim_10k_and_clear | 197575.50 | 74994.75 | -62.0% | 82934.71 | -58.0% | +4.0pp clone_slim_10k_and_drain_all | 425268.00 | 424679.50 | -0.1% | 432531.75 | +1.7% | +1.8pp clone_slim_10k_and_drain_half | 408679.00 | 358468.67 | -12.3% | 366904.50 | -10.2% | +2.1pp clone_slim_10k_and_into_iter | 184573.50 | 180805.00 | -2.0% | 188245.25 | +2.0% | +4.0pp clone_slim_10k_and_pop_all | 369476.00 | 370334.50 | +0.2% | 378684.50 | +2.5% | +2.3pp clone_slim_10k_and_remove_all | 582219.44 | 581719.69 | -0.1% | 590480.50 | +1.4% | +1.5pp clone_slim_10k_and_remove_half | 424686.50 | 373048.00 | -12.2% | 382718.00 | -9.9% | +2.3pp from_iter_rand_100 | 1832.99 | 1086.70 | -40.7% | 1194.53 | -34.8% | +5.9pp from_iter_rand_10_000 | 304447.00 | 231011.33 | -24.1% | 234360.00 | -23.0% | +1.1pp from_iter_seq_100 | 2045.17 | 750.12 | -63.3% | 896.15 | -56.2% | +7.1pp from_iter_seq_10_000 | 211268.33 | 80514.29 | -61.9% | 85877.83 | -59.4% | +2.5pp - btree::set benchmark | baseline | without drop | change | with drop | change | pp diff (with − without) -- | -- | -- | -- | -- | -- | -- clone_100 | 1913.17 | 605.95 | -68.3% | 745.54 | -61.0% | +7.3pp clone_100_and_clear | 1813.35 | 608.09 | -66.5% | 743.81 | -59.0% | +7.5pp clone_100_and_drain_all | 3960.52 | 3965.28 | +0.1% | 4088.26 | +3.2% | +3.1pp clone_100_and_drain_half | 4045.63 | 3408.90 | -15.7% | 3559.55 | -12.0% | +3.7pp clone_100_and_into_iter | 1676.32 | 1600.11 | -4.5% | 1721.67 | +2.7% | +7.3pp clone_100_and_pop_all | 2582.26 | 2562.19 | -0.8% | 2686.39 | +4.0% | +4.8pp clone_100_and_remove_all | 4574.45 | 4520.84 | -1.2% | 4671.70 | +2.1% | +3.3pp clone_100_and_remove_half | 2107.02 | 1533.22 | -27.2% | 1673.91 | -20.6% | +6.7pp clone_10k | 192719.50 | 65933.38 | -65.8% | 75038.88 | -61.1% | +4.7pp clone_10k_and_clear | 184669.60 | 66101.87 | -64.2% | 75375.25 | -59.2% | +5.0pp clone_10k_and_drain_all | 418832.00 | 417920.00 | -0.2% | 424436.00 | +1.3% | +1.6pp clone_10k_and_drain_half | 400446.00 | 348149.50 | -13.1% | 351997.00 | -12.1% | +1.0pp clone_10k_and_into_iter | 170359.60 | 163481.80 | -4.0% | 165757.25 | -2.7% | +1.3pp clone_10k_and_pop_all | 306021.67 | 307441.67 | +0.5% | 307585.00 | +0.5% | +0.0pp clone_10k_and_remove_all | 510750.88 | 511582.56 | +0.2% | 512938.25 | +0.4% | +0.3pp clone_10k_and_remove_half | 385672.00 | 337072.33 | -12.6% | 341705.50 | -11.4% | +1.2pp r? @Amanieu

…=joshtriplett std: add `fs::rename_noreplace` Tracking issue: rust-lang#161427 Accepted ACP: rust-lang/libs-team#131 ## Summary Add `fs::rename_noreplace`. Unlike `fs::rename`, the destination is never overwritten, instead returns `ErrorKind::AlreadyExists` if `to` already exists. Platform-specific APIs used: - [`renameat2`](https://man7.org/linux/man-pages/man2/renameat2.2.html) with `RENAME_NOREPLACE` flag on Linux and Android - `renamex_np` with `RENAME_EXCL` on Apple - [`MoveFileExW`](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexw) without the `MOVEFILE_REPLACE_EXISTING` flag on Windows. Extracted functionality into `rename_inner` to avoid duplication for `rename` and `rename_noreplace` - On other Unix platforms and on WASI, and on Linux, Android and Apple when the kernel or the filesystem doesn't support it, `link` followed by `unlink` is used instead. - Platforms with neither return `Unsupported`. Linux and Android case, has different error handling than Apple because the platforms report these conditions differently. On Linux the syscall may not exist at all (`ENOSYS`), and `EINVAL` covers "filesystem doesn't support the flag" and flag misuse (incorrect combinations of flags, as example). On Apple `renamex_np` is called directly, and Darwin use `ENOTSUP` for not supported case, and keeps `EINVAL` only for misuse combinations. > EINVAL An invalid flag was specified in flags. > EINVAL Both RENAME_NOREPLACE and RENAME_EXCHANGE were specified in flags. > EINVAL The filesystem does not support one of the flags in flags. [`renameat2`](https://man7.org/linux/man-pages/man2/renameat2.2.html) ## Open questions 1. `ENOSYS` on Linux and Android could be cached, unlike `EINVAL` case which on the same machine, when using different filesystem may return different result. In this PR I deliberately avoided adding caching to avoid premature optimization, but could add it if you think it worth it. 2. The `link` + `unlink` fallback can't move directories: `link` returns `EPERM`. Should it report `Unsupported` there instead? r? libs

Nuke `Unique` (and `ptr_internals`)

…plett std: add doctest to parent_id This operation is currently entirely untested. (I know because it shows up nowhere in the test failures when running the test suite in Miri, and Miri does not support this operation.) So let's add a test.

jhpratt · 2026-10-11T22:18:28Z

@bors r+ p=5 force

rust-bors · 2026-10-11T22:18:32Z

📌 Commit 48f4102 has been approved by jhpratt

It is now in the queue for this repository.

Rollup of 6 pull requests Successful merges: - #160597 (bootstrap: always build llvm's dylib when linking to it) - #162810 (vectorized vec::dedup pre-scan) - #162931 (directly deallocates the nodes instead of traversing every element when BTreemap dropping) - #162027 (std: add `fs::rename_noreplace`) - #164146 (Nuke `Unique` (and `ptr_internals`)) - #164151 (std: add doctest to parent_id)

rust-log-analyzer · 2026-10-12T00:58:59Z

The job test-aarch64-msvc-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

rust-bors · 2026-10-12T00:59:27Z

💔 Test for 11b57fc failed: CI. Failed job:

auto - test-aarch64-msvc-1 (web logs, enhanced plaintext logs)

rust-bors · 2026-10-12T01:13:16Z

PR #164151, which is a member of this rollup, was unapproved.

valentynkit and others added 17 commits September 27, 2026 22:43

std: add tests for fs::rename_noreplace

f09e0ef

std: clarify rename_noreplace crash guarantees

d0d58b4

Co-authored-by: Josh Triplett <josh@joshtriplett.org>

std: take plain u32 move flags on Windows

7b7ed95

windows-bindgen no longer generates the `MOVE_FILE_FLAGS` alias, so `u32` is used instead.

vectorized vec::dedup pre-scan

2ad8211

directly drop the tree instead of traversing every element when BTree…

926a9d0

…Map dropping

Nuke Unique

32fd83f

std: add doctest to parent_id

5fd1cb6

minor: note dylib link and build vars are ideally equal

a8d5c6c

Rollup merge of rust-lang#164146 - maxdexh:nuke-unique, r=hanna-kruppe

b4972fb

Nuke `Unique` (and `ptr_internals`)

rust-bors Bot added the rollup A PR which is a rollup label Oct 11, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 11, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 12, 2026

jhpratt mentioned this pull request Oct 12, 2026

std: add doctest to parent_id #164151

Merged

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 12, 2026

jhpratt closed this Oct 12, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 12, 2026

jhpratt deleted the rollup-iSnakUS branch October 12, 2026 01:15

Navigation Menu

Repository navigation

Rollup of 6 pull requests - #164179

Rollup of 6 pull requests#164179
jhpratt wants to merge 17 commits into
rust-lang:mainfrom
jhpratt:rollup-iSnakUS

jhpratt commented Oct 11, 2026

Uh oh!

jhpratt commented Oct 11, 2026

Uh oh!

rust-bors Bot commented Oct 11, 2026

Uh oh!

This comment has been minimized.

rust-log-analyzer commented Oct 12, 2026

Uh oh!

rust-bors Bot commented Oct 12, 2026

Uh oh!

rust-bors Bot commented Oct 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Conversation

jhpratt commented Oct 11, 2026

Uh oh!

jhpratt commented Oct 11, 2026

Uh oh!

rust-bors Bot commented Oct 11, 2026

Uh oh!

This comment has been minimized.

rust-log-analyzer commented Oct 12, 2026

Uh oh!

rust-bors Bot commented Oct 12, 2026

Uh oh!

rust-bors Bot commented Oct 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants