Remove eval_always for privacy.

[cjgillot]

Split off #86056
r? @ghost

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 186f9d095122f4c1175c73239612b5cfe6a5fd76 with merge 5f3b89109d034f520ab45c8d21b99c2d8d9b873e...

[bors]

☀️ Try build successful - checks-actions
Build commit: 5f3b89109d034f520ab45c8d21b99c2d8d9b873e (5f3b89109d034f520ab45c8d21b99c2d8d9b873e)

[rust-timer]

Queued 5f3b89109d034f520ab45c8d21b99c2d8d9b873e with parent 4961b10, future comparison URL.

[rust-timer]

Finished benchmarking commit (5f3b89109d034f520ab45c8d21b99c2d8d9b873e): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

• Large improvement in instruction counts (up to -1.8% on incr-unchanged builds of ripgrep)
• Moderate regression in instruction counts (up to 0.9% on incr-full builds of externs)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 186f9d095122f4c1175c73239612b5cfe6a5fd76 with merge 2dc3d8cad0559aa4da59885534dbe68273c86dc7...

[bors]

☀️ Try build successful - checks-actions
Build commit: 2dc3d8cad0559aa4da59885534dbe68273c86dc7 (2dc3d8cad0559aa4da59885534dbe68273c86dc7)

[rust-timer]

Queued 2dc3d8cad0559aa4da59885534dbe68273c86dc7 with parent dd549dc, future comparison URL.

[rust-timer]

Finished benchmarking commit (2dc3d8cad0559aa4da59885534dbe68273c86dc7): comparison url.

Summary: This change led to large relevant mixed results 🤷 in compiler performance.

• Large improvement in instruction counts (up to -1.7% on incr-unchanged builds of ripgrep)
• Moderate regression in instruction counts (up to 0.9% on incr-full builds of externs)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

[Aaron1011]

@cjgillot: The performance still looks somewhat mixed. Could you try running perf builds where only one of privacy_access_levels and check_private_in_public is changed at a time?

[apiraino]

Does this need another spin of @rust-timer to test again performance diff?

[apiraino]

switching to waiting on PR author (as I think it reflects the current status), but please flip the switch if it's not the case

@rustbot author