Skip to content

Pick the largest niche even if the largest niche is wrapped around #144577

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 30, 2025

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jul 28, 2025

fixes #144388

r? @scottmcm

@rustbot 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 Jul 28, 2025
Comment on lines 76 to -79
assert::is_transmutable::<OptionLike, u8>();
assert::is_transmutable::<V0, OptionLike>();
assert::is_transmutable::<V1, OptionLike>();
assert::is_transmutable::<V254, OptionLike>();
assert::is_transmutable::<V255, OptionLike>();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jswrenn I'm not sure how to properly fix this test to check what it was checking before. I guess I could create enums with all but a few variants?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So long as you're confident that the revised test will fail if the niche selection process is changed, I'm not too opinionated about the exact approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah oops. Should have done this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will create a PR, but it may take 4 weeks as I'm going on vacation

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem; happy to review it when you do so!

Comment on lines -110 to +111
// If there are no negative values, we can use the unsigned fit.
if min >= 0 {
// Pick the smallest fit.
if unsigned_fit <= signed_fit {
Copy link
Contributor Author

@oli-obk oli-obk Jul 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This affected no tests on its own (but is needed for this PR, as previously it was assumed that min < max), but I think it is strictly better, I'm not expecting signed ops to be slower or anything

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Signed ops can actually optimize better, even, since sub nuw %x, 1 turns into add %x, -1 whereas sub nsw %x, 1 keeps its nowrap flag becoming add nsw %x, -1.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But yeah, if it's the same integer size either way it probably doesn't matter which is chosen.

@rust-log-analyzer

This comment has been minimized.

.map(|(_, val)| {
if discr_type.is_signed() {
// sign extend the raw representation to be an i128
(val << (128 - bits)) >> (128 - bits)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you have the discr_int.size(), so you can do https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/struct.Size.html#method.sign_extend instead of writing this out.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point. it was preexisting, so I'll pack it into a separate commit.

// Since they were sorted, we can now compute the niche sizes and pick the largest.
let discriminants = discriminants.zip(next_discriminants);
let largest_niche = discriminants.max_by_key(|&(start, end)| {
if start <= end { end - start } else { discr_int.signed_max() - (start - end) }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I'm kinda surprised to see the start <= end check here. Since we're calculating a distance in a wrapping range, could it be end.wrapping_sub(start)? Or I guess if we need to trim that to the type in question, size.truncate(end.wrapping_sub(start))?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(There's also something going weird here in general because the CI failure is here.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI failure is only for 128 bit discriminants with niches larger than i128::MAX because those turn negative

Got a fix and comments locally, just forgot to push

@scottmcm
Copy link
Member

Thanks for fixing! Looks good.
@bors r+

@bors
Copy link
Collaborator

bors commented Jul 29, 2025

📌 Commit 219bad4 has been approved by scottmcm

It is now in the queue for this repository.

@bors bors 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 Jul 29, 2025
@bors
Copy link
Collaborator

bors commented Jul 30, 2025

⌛ Testing commit 219bad4 with merge 919c409...

@bors
Copy link
Collaborator

bors commented Jul 30, 2025

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 919c409 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 30, 2025
@bors bors merged commit 919c409 into rust-lang:master Jul 30, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 30, 2025
Copy link
Contributor

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 c8bb4e8 (parent) -> 919c409 (this PR)

Test differences

Show 6 test diffs

Stage 1

  • [ui] tests/ui/enum-discriminant/wrapping_niche.rs: [missing] -> pass (J1)

Stage 2

  • [ui] tests/ui/enum-discriminant/wrapping_niche.rs: [missing] -> pass (J0)

Additionally, 4 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 919c40924373c248315a76618d8c52d39aed5e6e --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. dist-aarch64-msvc: 8158.0s -> 4916.4s (-39.7%)
  2. aarch64-apple: 6746.8s -> 5145.3s (-23.7%)
  3. x86_64-apple-1: 7963.5s -> 6973.0s (-12.4%)
  4. aarch64-gnu-debug: 3968.9s -> 4397.6s (10.8%)
  5. x86_64-apple-2: 5552.5s -> 6111.8s (10.1%)
  6. x86_64-gnu-nopt: 8220.9s -> 7455.1s (-9.3%)
  7. aarch64-gnu: 6634.7s -> 7158.8s (7.9%)
  8. dist-ohos-aarch64: 4043.7s -> 4342.6s (7.4%)
  9. x86_64-rust-for-linux: 3187.5s -> 2953.4s (-7.3%)
  10. dist-apple-various: 4493.2s -> 4817.7s (7.2%)
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
Copy link
Collaborator

Finished benchmarking commit (919c409): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary -1.6%, secondary 0.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)
0.8% [0.8%, 0.8%] 1
Improvements ✅
(primary)
-1.6% [-1.8%, -1.5%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.6% [-1.8%, -1.5%] 2

Cycles

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

Binary size

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

Bootstrap: 470.143s -> 468.849s (-0.28%)
Artifact size: 376.75 MiB -> 376.81 MiB (0.02%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enum valid_range calculations should be able to generate wraparound WrappingRanges for unsigned discriminants
7 participants