privacy: Assert that compared visibilities are (usually) ordered

[petrochenkov]

View all comments

And make "greater than" (>) the new primary operation for comparing visibilities instead of "is at least" (>=).

[rustbot]

r? @adwinwhite

rustbot has assigned @adwinwhite.
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 69 candidates
• Random selection from 12 candidates

[petrochenkov]

@bors try @rust-timer queue

[petrochenkov]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c52563 (0c5256376cfe5d7821eaee808f971cc64299b5ff, parent: 12f35ad39ed3e39df4d953c46d4f6cc6c82adc96)

[rust-timer]

Finished benchmarking commit (0c52563): comparison URL.

Overall result: ❌ regressions - 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)	0.2%	[0.2%, 0.2%]	9
Regressions ❌ (secondary)	0.6%	[0.3%, 1.7%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.2%, 0.2%]	9

Max RSS (memory usage)

Results (primary 1.6%)

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

	mean	range	count
Regressions ❌ (primary)	1.6%	[1.1%, 2.1%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.6%	[1.1%, 2.1%]	2

Cycles

Results (secondary -3.3%)

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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.3%	[-4.4%, -2.1%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 489.936s -> 490.568s (0.13%)
Artifact size: 394.18 MiB -> 394.10 MiB (-0.02%)

[petrochenkov]

One small regression on libc (which is a sort of stress test for large number of imports and other items).
I think we can merge like this, or switch to debug_assert, but then only @matthiaskrgr's fuzzing or something like that will find the potential issues.

[petrochenkov]

This could also be potentially blocked on #155213 which addresses on of the FIXMEs here.

[adwinwhite]

@petrochenkov Sorry but perhaps you can manually pick a reviewer who's familiar with this part? I'm not sure that reroll can get to the right person.

[petrochenkov]

I analyzed one of the FIXMEs, it will only be unordered in erroneous cases after some fixes, so we'll need a delayed_bug instead of panic, so I'll just change it now.

[rustbot]

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.

[petrochenkov]

@rustbot ready

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

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

--- BACKTRACE vvv
   0: <bootstrap::utils::exec::DeferredCommand>::finish_process
             at /checkout/src/bootstrap/src/utils/exec.rs:939:17
   1: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
             at /checkout/src/bootstrap/src/utils/exec.rs:831:21
   2: <bootstrap::utils::exec::ExecutionContext>::run
             at /checkout/src/bootstrap/src/utils/exec.rs:741:45
   3: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
             at /checkout/src/bootstrap/src/utils/exec.rs:339:27
   4: bootstrap::core::build_steps::toolstate::checkout_toolstate_repo
             at /checkout/src/bootstrap/src/core/build_steps/toolstate.rs:319:10
   5: <bootstrap::core::build_steps::toolstate::ToolStateCheck as bootstrap::core::builder::Step>::run
             at /checkout/src/bootstrap/src/core/build_steps/toolstate.rs:177:9
   6: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::toolstate::ToolStateCheck>
             at /checkout/src/bootstrap/src/core/builder/mod.rs:1579:36
   7: <bootstrap::core::build_steps::toolstate::ToolStateCheck as bootstrap::core::builder::Step>::make_run
             at /checkout/src/bootstrap/src/core/build_steps/toolstate.rs:230:21
   8: <bootstrap::core::builder::StepDescription>::maybe_run
             at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
   9: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
             at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:232:18
  10: <bootstrap::core::builder::Builder>::run_step_descriptions
             at /checkout/src/bootstrap/src/core/builder/mod.rs:1122:9
  11: <bootstrap::core::builder::Builder>::execute_cli
             at /checkout/src/bootstrap/src/core/builder/mod.rs:1101:14
  12: <bootstrap::Build>::build
             at /checkout/src/bootstrap/src/lib.rs:799:25
  13: bootstrap::main
             at /checkout/src/bootstrap/src/bin/main.rs:130:11
  14: <fn() as core::ops::function::FnOnce<()>>::call_once
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/core/src/ops/function.rs:250:5
  15: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/sys/backtrace.rs:166:18
  16: std::rt::lang_start::<()>::{closure#0}
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/rt.rs:206:18
  17: <&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe as core::ops::function::FnOnce<()>>::call_once
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/core/src/ops/function.rs:287:21
  18: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panicking.rs:581:40
  19: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panicking.rs:544:19
  20: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe, i32>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panic.rs:359:14
  21: std::rt::lang_start_internal::{closure#0}
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/rt.rs:175:24
  22: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
             at /rustc/ef0fb8a2563200e322fa4419f09f65a63742038c/library/std/src/panicking.rs:581:40
---
  29: __libc_start_main
  30: _start


Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:00:03
  local time: Thu Apr 23 16:34:01 UTC 2026
  network time: Thu, 23 Apr 2026 16:34:01 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[petrochenkov]

(The CI failure is spurious.)

[adwinwhite]

I guess unordered comparison doesn't make sense anyway so it's intended and fine to err in those cases.

@bors r+

[rust-bors]

📌 Commit 714df2b has been approved by adwinwhite

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: adwinwhite
Duration: 3h 16m 30s
Pushing 9838411 to main...

[github-actions]

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 fb76025 (parent) -> 9838411 (this PR)

Test differences

Show 25 test diffs

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

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 9838411cb723b60dc62b1625751075c4d933b992 --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

1. x86_64-gnu-llvm-22-3: 1h 37m -> 2h 2m (+25.7%)
2. dist-i686-mingw: 2h 12m -> 2h 44m (+24.1%)
3. dist-x86_64-illumos: 1h 23m -> 1h 42m (+23.4%)
4. aarch64-apple: 3h 17m -> 2h 52m (-12.3%)
5. x86_64-msvc-ext3: 1h 43m -> 1h 56m (+12.2%)
6. x86_64-gnu-llvm-21-1: 1h 7m -> 1h 14m (+11.0%)
7. dist-aarch64-apple: 1h 38m -> 1h 48m (+10.1%)
8. x86_64-gnu-gcc: 1h 10m -> 1h 3m (-10.0%)
9. dist-aarch64-llvm-mingw: 1h 36m -> 1h 45m (+9.6%)
10. x86_64-msvc-1: 2h 45m -> 2h 29m (-9.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]

Finished benchmarking commit (9838411): comparison URL.

Overall result: ❌ regressions - please read:

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

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.7%]	12
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.2%, 0.7%]	12

Max RSS (memory usage)

Results (secondary -2.2%)

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)	3.6%	[1.0%, 6.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.0%	[-7.7%, -2.8%]	3
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -0.6%)

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

Binary size

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

Bootstrap: 487.131s -> 486.61s (-0.11%)
Artifact size: 394.07 MiB -> 394.05 MiB (-0.01%)

[Mark-Simulacrum]

Marking perf regression as triaged. The tradeoff was evaluated as part of PR discussion and we have a follow-up that may mitigate some of the impact in #155608.