Rollup of 8 pull requests by matthiaskrgr · Pull Request #141944 · rust-lang/rust

matthiaskrgr · 2025-06-03T05:03:47Z

Successful merges:

Clarify &mut-methods' docs on sync::OnceLock #140715 (Clarify &mut-methods' docs on sync::OnceLock)
Async drop - type instead of async drop fn, fixes #140484 #141677 (Async drop - type instead of async drop fn, fixesICE: unexpected sort of node in fn_sig(): ImplItem(ImplItem #140484)
Overhaul UsePath #141741 (Overhaul UsePath)
Fixed a typo in ManuallyDrop's doc #141873 (Fixed a typo in ManuallyDrop's doc)
Don't declare variables in ExprKind::Let in invalid positions #141876 (Don't declare variables in ExprKind::Let in invalid positions)
Add missing 2015 edition directives #141886 (Add missing 2015 edition directives)
Add missing dyn keywords to tests that do not test for them #141889 (Add missing dyn keywords to tests that do not test for them)
Fix borrowck mentioning a name from an external macro we (deliberately) don't save #141891 (Fix borrowck mentioning a name from an external macro we (deliberately) don't save)

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

…re don't ICE now

I find it much easier to think about in the positive sense.

These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition

This ensures that these tests can be run on editions other than 2015

…er crate

`UsePath` contains a `SmallVec<[Res; 3]>`. This holds up to three `Res` results, one per namespace (type, value, or macro). `lower_import_res` takes a `PerNS<Option<Res<NodeId>>>` result and lowers it into the `SmallVec`. This is pretty weird. The input `PerNS` makes it clear which `Res` belongs to which namespace, but the `SmallVec` throws that information away. And code that operates on the `SmallVec` tends to use iteration (or even just grabbing the first entry!) without knowing which namespace the `Res` belongs to. Even weirder! Also, `SmallVec` is an overly flexible type to use here, because it can contain any number of elements (even though it's optimized for 3 in this case). This commit changes `UsePath` so it also contains a `PerNS<Option<Res<HirId>>>`. This type preserves more information and is more self-documenting. The commit also changes a lot of the use sites to access the result for a particular namespace. E.g. if you're looking up a trait, it will be in the `Res` for the type namespace if it's present; it's silly to look in the `Res` for the value namespace or macro namespace. Overall I find the new code much easier to understand. However, some use sites still iterate. These now use `present_items` because that filters out the `None` results. Also, `redundant_pub_crate.rs` gets a bigger change. A `UseKind:ListStem` item gets no `Res` results, which means the old `all` call in `is_not_macro_export` would succeed (because `all` succeeds on an empty iterator) and the `ListStem` would be ignored. This is what we want, but was more by luck than design. The new code detects `ListStem` explicitly. The commit generalizes the name of that function accordingly. Finally, the commit also removes the `use_path` arena, because `PerNS<Option<Res>>` impls `Copy` (unlike `SmallVec`) and it can be allocated in the arena shared by all `Copy` types.

…ss35 Clarify &mut-methods' docs on sync::OnceLock Three small changes to the docs of `sync::OnceLock`: * The docs for `OnceLock::take()` used to [say](https://doc.rust-lang.org/std/sync/struct.OnceLock.html#method.take) "**Safety** is guaranteed by requiring a mutable reference." (emphasis mine). While technically correct, imho its not necessary to even mention safety - as opposed to unsafety - here: Safety never comes up wrt `OnceLock`, as there is (currently) no way to interact with a `OnceLock` in an unsafe way; there are no unsafe methods on `OnceLock`, so there is "safety" guarantee required anywhere. What we simply meant to say is "**Synchronization** is guaranteed...". * I've add that phrase to the other methods of `OnceLock` which take a `&mut self`, to highlight the fact that having a `&mut OnceLock` guarantees that synchronization with other threads is not required. This is the same as with [`Mutex::get_mut()`](https://doc.rust-lang.org/std/sync/struct.Mutex.html#method.get_mut), [`Cell::get_mut()`](https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut), and others. * In that spirit, the half-sentence "or being initialized" was removed from `get_mut()`, as there is no way that the `OnceLock` is being initialized while we are holding `&mut` to it. Probably a copy&paste from `.get()`

…ted-type-instead-of-drop-fn-fix, r=oli-obk Async drop - type instead of async drop fn, fixesrust-lang#140484Fixes: rust-lang#140484Fixes: rust-lang#140500 Fixes ICE, when type is provided in AsyncDrop trait instead of `async fn drop()`. Fixes ICE, when async drop fn has wrong signature.

…trochenkov Overhaul `UsePath` It currently uses `SmallVec<[Res; 3]>` which is really weird. Details in the individual commits. r? `@petrochenkov`

Fixed a typo in `ManuallyDrop`'s doc I noticed a typo in `ManuallyDrop`'s documentation (someone wrote "iff" instead of "if"). I fixed it in this PR.

…SparrowLii Don't declare variables in `ExprKind::Let` in invalid positions Handle `let` expressions in invalid positions specially during resolve in order to avoid making destructuring-assignment expressions that reference (invalid) variables that have not yet been delcared yet. See further explanation in test and comment in the source. Fixesrust-lang#141844

…es, r=compiler-errors Add missing 2015 edition directives These tests specifically test 2015 edition behavior, so ensure that they can only be run with this edition

…rochenkov Add missing `dyn` keywords to tests that do not test for them This ensures that these tests can be run on editions other than 2015

Fix borrowck mentioning a name from an external macro we (deliberately) don't save Most of the info is already in the title 🤷 Closesrust-lang#141764

matthiaskrgr · 2025-06-03T05:04:13Z

@bors r+ rollup=never p=5

bors · 2025-06-03T05:04:16Z

📌 Commit f3622ea has been approved by matthiaskrgr

It is now in the queue for this repository.

bors · 2025-06-03T06:34:48Z

⌛ Testing commit f3622ea with merge c68032f...

bors · 2025-06-03T09:51:28Z

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing c68032f to master...

rust-timer · 2025-06-03T09:53:47Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#140715	Clarify &mut-methods' docs on sync::OnceLock	`5c6bede4f444c7ffd0ed90c005dc45e2ec3c87a6` (link)
#141677	Async drop - type instead of async drop fn, fixes #140484	`b0c58d95ded931e8e60c38b98186b955265a4586` (link)
#141741	Overhaul `UsePath`	`43f2e74af7a92fdf71f89aa79092c2113502b003` (link)
#141873	Fixed a typo in `ManuallyDrop`'s doc	`e9b293e63db81b7f7c3c5921a10c04b82b5e3d2f` (link)
#141876	Don't declare variables in `ExprKind::Let` in invalid posit…	`7a62eed382236ed6d06de5e2b62830c5352cbc92` (link)
#141886	Add missing 2015 edition directives	`833e1af43a4e7b0f93b06c2fc8da485c32069a7c` (link)
#141889	Add missing `dyn` keywords to tests that do not test for th…	`67dec67871847ef348a6299a63f1ddcaea1e7a40` (link)
#141891	Fix borrowck mentioning a name from an external macro we (d…	`292f076809f2ff45958e06c5f8e94579d966840a` (link)

previous master: b17dba4518

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

github-actions · 2025-06-03T09:54:34Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing b17dba4 (parent) -> c68032f (this PR)

Test differences

Show 42 test diffs

Stage 1

[crashes] tests/crashes/140484.rs: pass -> [missing] (J0)
[crashes] tests/crashes/140500.rs: pass -> [missing] (J0)
[ui] tests/ui/async-await/async-drop/type-parameter.rs: [missing] -> pass (J0)
[ui] tests/ui/async-await/async-drop/unexpected-sort.rs: [missing] -> pass (J0)
[ui] tests/ui/destructuring-assignment/bad-let-in-destructure.rs: [missing] -> pass (J0)
[ui] tests/ui/macros/borrowck-error-in-macro.rs: [missing] -> pass (J0)

Stage 2

[crashes] tests/crashes/140484.rs: pass -> [missing] (J1)
[crashes] tests/crashes/140500.rs: pass -> [missing] (J1)
[ui] tests/ui/async-await/async-drop/type-parameter.rs: [missing] -> pass (J2)
[ui] tests/ui/async-await/async-drop/unexpected-sort.rs: [missing] -> pass (J2)
[ui] tests/ui/destructuring-assignment/bad-let-in-destructure.rs: [missing] -> pass (J2)
[ui] tests/ui/macros/borrowck-error-in-macro.rs: [missing] -> pass (J2)

Additionally, 30 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard c68032fd4c442d275f4daa571ba19c076106b490 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

dist-aarch64-linux: 5453.4s -> 7614.6s (39.6%)
x86_64-apple-2: 5130.5s -> 6250.0s (21.8%)
dist-apple-various: 6439.6s -> 7753.8s (20.4%)
x86_64-apple-1: 7636.5s -> 8415.5s (10.2%)
dist-x86_64-apple: 9431.4s -> 8638.9s (-8.4%)
dist-x86_64-netbsd: 5336.3s -> 5049.8s (-5.4%)
x86_64-gnu-llvm-20-1: 3691.6s -> 3883.5s (5.2%)
x86_64-gnu-nopt: 5613.3s -> 5900.2s (5.1%)
aarch64-apple: 5094.9s -> 5325.4s (4.5%)
x86_64-gnu-llvm-19-3: 6744.5s -> 7042.9s (4.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-06-03T21:28:37Z

Finished benchmarking commit (c68032f): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.3%]	5
Improvements ✅ (primary)	-0.6%	[-1.1%, -0.2%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-1.1%, -0.2%]	3

Max RSS (memory usage)

Results (primary -1.2%, secondary -2.1%)

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.8%	[0.8%, 0.8%]	1
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-3.0%	[-6.7%, -1.1%]	3
All ❌✅ (primary)	-1.2%	[-1.2%, -1.2%]	1

Cycles

Results (secondary -3.0%)

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)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 743.703s -> 743.521s (-0.02%)
Artifact size: 372.32 MiB -> 372.32 MiB (0.00%)

panstromek · 2025-06-09T11:50:40Z

perf triage:

Few regressions in unused-warnings. This looks like noise to me for the most part - check and opt builds don't agree on whether frontend times regressed or not and the benchmark since returned to previous state (partly in another rollup).

I would suspect #141741 to be the cause, because it touched use statements and unused-warnings is a large list of use statements, but that one had different pre-merge results.

I don't think this is worth digging into, though.

@rustbot label: +perf-regression-triaged

matthiaskrgr · 2025-06-03T05:03:47Z

Successful merges:

Clarify &mut-methods' docs on sync::OnceLock #140715 (Clarify &mut-methods' docs on sync::OnceLock)
Async drop - type instead of async drop fn, fixes #140484 #141677 (Async drop - type instead of async drop fn, fixesICE: unexpected sort of node in fn_sig(): ImplItem(ImplItem #140484)
Overhaul UsePath #141741 (Overhaul UsePath)
Fixed a typo in ManuallyDrop's doc #141873 (Fixed a typo in ManuallyDrop's doc)
Don't declare variables in ExprKind::Let in invalid positions #141876 (Don't declare variables in ExprKind::Let in invalid positions)
Add missing 2015 edition directives #141886 (Add missing 2015 edition directives)
Add missing dyn keywords to tests that do not test for them #141889 (Add missing dyn keywords to tests that do not test for them)
Fix borrowck mentioning a name from an external macro we (deliberately) don't save #141891 (Fix borrowck mentioning a name from an external macro we (deliberately) don't save)