resolve: Evaluate private visibilities eagerly in eff vis computation by petrochenkov · Pull Request #156185 · rust-lang/rust

petrochenkov · 2026-05-05T11:00:17Z

It's cheaper to evaluate them now when Declarations keep their parent modules.

rustbot · 2026-05-05T11:00:21Z

rustbot has assigned @folkertdev.
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: compiler
compiler expanded to 73 candidates
Random selection from 19 candidates

petrochenkov · 2026-05-05T11:00:26Z

@bors try @rust-timer queue

resolve: Try removing questionable optimizations in eff vis computation

rust-bors · 2026-05-05T13:09:37Z

☀️ Try build successful (CI)
Build commit: b88d160 (b88d160c3a88b6a02a3856463a035a8b334c6f57, parent: 4feb7221f4d445120a5061b16ce7222adbfdf6f6)

rust-timer · 2026-05-05T13:51:18Z

Finished benchmarking commit (b88d160): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@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)	1.3%	[0.2%, 5.4%]	22
Regressions ❌ (secondary)	1.0%	[0.1%, 4.4%]	30
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.2%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[-0.3%, 5.4%]	30

Max RSS (memory usage)

Results (primary 1.7%, secondary -0.1%)

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

	mean	range	count
Regressions ❌ (primary)	2.6%	[1.5%, 3.2%]	4
Regressions ❌ (secondary)	1.2%	[1.0%, 1.5%]	3
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	2
All ❌✅ (primary)	1.7%	[-2.1%, 3.2%]	5

Cycles

Results (primary 3.5%, secondary 1.1%)

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

	mean	range	count
Regressions ❌ (primary)	4.7%	[2.5%, 6.0%]	5
Regressions ❌ (secondary)	2.2%	[0.7%, 3.7%]	4
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-0.5%	[-0.6%, -0.4%]	3
All ❌✅ (primary)	3.5%	[-2.2%, 6.0%]	6

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 495.518s -> 495.363s (-0.03%)
Artifact size: 394.42 MiB -> 394.49 MiB (0.02%)

petrochenkov · 2026-05-05T15:46:43Z

@bors try @rust-timer queue

resolve: Try removing questionable optimizations in eff vis computation

petrochenkov · 2026-05-05T17:20:45Z

@bors try @rust-timer queue

rust-timer · 2026-05-07T20:56:27Z

Finished benchmarking commit (71f45f1): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing 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)	-2.3%	[-8.6%, -0.2%]	12
Improvements ✅ (secondary)	-1.6%	[-2.5%, -0.3%]	14
All ❌✅ (primary)	-2.3%	[-8.6%, -0.2%]	12

Max RSS (memory usage)

Results (primary 1.0%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	4.4%	[4.4%, 4.4%]	1
Regressions ❌ (secondary)	1.8%	[0.4%, 2.4%]	4
Improvements ✅ (primary)	-2.4%	[-2.4%, -2.4%]	1
Improvements ✅ (secondary)	-2.2%	[-2.7%, -1.5%]	3
All ❌✅ (primary)	1.0%	[-2.4%, 4.4%]	2

Cycles

Results (primary -7.8%, secondary -7.8%)

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)	2.6%	[0.5%, 7.4%]	6
Improvements ✅ (primary)	-7.8%	[-9.1%, -6.8%]	3
Improvements ✅ (secondary)	-11.1%	[-27.5%, -0.6%]	19
All ❌✅ (primary)	-7.8%	[-9.1%, -6.8%]	3

Binary size

Results (secondary 0.0%)

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

Bootstrap: 499.128s -> 500.469s (0.27%)
Artifact size: 395.02 MiB -> 395.00 MiB (-0.00%)

petrochenkov · 2026-05-08T04:58:37Z

What's going on with cycles for tt-muncher though.

Now tt-muncher cycles are very green instead, seems like it's just unreliable.

petrochenkov · 2026-05-08T04:59:51Z

@bors try @rust-timer queue

resolve: Evaluate private visibilities eagerly in eff vis computation

rust-bors · 2026-05-08T07:09:53Z

☀️ Try build successful (CI)
Build commit: e3104ed (e3104edd514605f22290761b3e65b7eb51c2d9a0, parent: 63b1dfc0e00fd6f8ad7cd8817fc712e7d9b7be59)

petrochenkov · 2026-05-08T10:23:17Z

@rustbot ready

folkertdev · 2026-05-09T08:51:04Z

@rustbot reroll

petrochenkov · 2026-05-09T11:03:54Z

cc @mu001999

resolve: Set correct parent and expansion for `self` declarations Follow up to rust-lang#146972 and rust-lang#154313. The `parent` seems to not be used yet, it will ICE if used (rust-lang#156185 uses it). The `expn_id` is only relevant to macros 2.0, I won't bother coming up with a test.

mu001999 · 2026-05-09T14:59:09Z

            // Set the given effective visibility level to `Level::Direct` and
            // sets the rest of the `use` chain to `Level::Reexported` until
            // we hit the actual exported item.
+            let orig_private_vis = self.current_private_vis;


Could we pass self.current_private_vis as an explicit parameter like private_vis: Visibility in the parts other than visit_item? That way, we wouldn’t need to save and restore self.current_private_vis.

View changes since the review

We have to keep current_private_vis in the visitor at least in some cases because in AST visitor when visiting e.g. a struct we don't know it's parent module.
a1d65ae shows how it looks if private visibility is always passed when possible.

main...petrochenkov:rust:queffvis2 shows how it looks if private visibility is only passed to update_(import,def).
It may actually be slightly nicer than the PR version.

rustbot · 2026-05-09T18:33:31Z

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.

rustbot assigned folkertdev May 5, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 5, 2026