Skip to content

constify Step trait and all of its implementations#153821

Merged
rust-bors[bot] merged 1 commit intorust-lang:mainfrom
Lars-Schumann:const-step
Mar 28, 2026
Merged

constify Step trait and all of its implementations#153821
rust-bors[bot] merged 1 commit intorust-lang:mainfrom
Lars-Schumann:const-step

Conversation

@Lars-Schumann
Copy link
Copy Markdown
Contributor

@Lars-Schumann Lars-Schumann commented Mar 13, 2026

constifying Step trait and all of its implementations, with some friendly help from const_cmp

@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. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 13, 2026
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented Mar 13, 2026

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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: @scottmcm, libs
  • @scottmcm, libs expanded to 8 candidates
  • Random selection from Mark-Simulacrum, joboet, scottmcm

@Lars-Schumann Lars-Schumann changed the title constify Step trait and all of its implementations constify Step trait and all of its implementations Mar 13, 2026
@Lars-Schumann Lars-Schumann changed the title constify Step trait and all of its implementations constify Step trait and all of its implementations Mar 13, 2026
// CHECK: %[[B01:.+]] = load i16, ptr %[[PB01]]
// CHECK-NOT: cmp
// CHECK: %[[EQ01:.+]] = icmp eq i16 %[[A01]], %[[B01]]
// CHECK-NEXT: br i1 %[[EQ01]], label %{{.+}}, label %[[EXIT_U]]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do we know what happened to cause this? Maybe one of the const-hack closure -> function conversions above changed inlining? If I'm reading this right, the new IR seems worse -- 0/2/4/6 vs. 0/4/6/2 seems like it might be at least a tiny regression.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

cc @scottmcm in case you have thoughts on the new IR -- I think it meets the goal of when we added it still...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

my guess was this swapped basically by chance and since the rest is the same it should be fine.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It's definitely weird that it swapped things like this in such a way that the only branch to the first block is from below -- or at least I'm assuming that that's why it ended up without a header? Should probably try to fix that so the block name substitutions are still meaningful?

But in general, I'm not worried about the block order of the things, since that's really LLVM's business not ours, and is highly divorced from what we can do in code anyway.

That said, I'm definitely sad about all these const hacks, and kinda wish they'd stop until the features existed -- if it needs const closures it should use const closures, for example. But that's not really my call :/

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Const closures were reimplemented very recently and to my knowledge aren't supposed to be used in the std lib yet, these are rather tame const hacks.

let rhs = &right[..l];

for i in 0..l {
// FIXME(const-hack): revert this to `for i in 0..l` once `impl const Iterator for Range<T>`
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Definitely sad that this PR fixing Step that's the main thing this needs still can't just use in 0..l 😢

Copy link
Copy Markdown
Contributor Author

@Lars-Schumann Lars-Schumann Mar 23, 2026

Choose a reason for hiding this comment

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

Kind of a chicken and egg problem here, this is pretty much the last thing needed for const Ranges.

@Mark-Simulacrum
Copy link
Copy Markdown
Member

@bors r+ rollup=never

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Mar 27, 2026

📌 Commit 6e2522e has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@rust-bors rust-bors bot 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 Mar 27, 2026
@rust-bors

This comment has been minimized.

@rust-bors rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 28, 2026
@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors bot commented Mar 28, 2026

☀️ Test successful - CI
Approved by: Mark-Simulacrum
Duration: 3h 9m 26s
Pushing 7e28c74 to main...

@rust-bors rust-bors bot merged commit 7e28c74 into rust-lang:main Mar 28, 2026
12 checks passed
@rustbot rustbot added this to the 1.96.0 milestone Mar 28, 2026
@github-actions
Copy link
Copy Markdown
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 79531c5 (parent) -> 7e28c74 (this PR)

Test differences

Show 332 test diffs

332 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 7e28c7438a7b0c79a09724ba799d32ed461beb72 --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. tidy: 2m 29s -> 2m 49s (+13.9%)
  2. armhf-gnu: 1h 34m -> 1h 22m (-12.7%)
  3. dist-aarch64-msvc: 1h 46m -> 1h 33m (-12.7%)
  4. x86_64-gnu-stable: 2h 24m -> 2h 6m (-12.6%)
  5. pr-check-2: 41m 17s -> 36m 24s (-11.8%)
  6. dist-android: 26m 46s -> 29m 42s (+11.0%)
  7. arm-android: 1h 50m -> 1h 39m (-10.5%)
  8. i686-gnu-nopt-1: 2h 17m -> 2h 4m (-9.5%)
  9. i686-gnu-2: 1h 41m -> 1h 32m (-9.0%)
  10. aarch64-gnu-debug: 1h 12m -> 1h 5m (-8.9%)
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
Copy Markdown
Collaborator

Finished benchmarking commit (7e28c74): comparison URL.

Overall result: ❌ regressions - 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

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

mean range count
Regressions ❌
(primary)
0.8% [0.4%, 1.2%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.8% [0.4%, 1.2%] 2

Max RSS (memory usage)

Results (primary 2.6%)

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

mean range count
Regressions ❌
(primary)
2.6% [2.6%, 2.6%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.6% [2.6%, 2.6%] 1

Cycles

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

Binary size

Results (primary 1.2%)

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

mean range count
Regressions ❌
(primary)
1.2% [1.2%, 1.2%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.2% [1.2%, 1.2%] 1

Bootstrap: 484.626s -> 484.417s (-0.04%)
Artifact size: 395.06 MiB -> 394.97 MiB (-0.02%)

@rustbot rustbot added the perf-regression Performance regression. label Mar 28, 2026
@Lars-Schumann Lars-Schumann deleted the const-step branch March 29, 2026 15:51
@Kobzol
Copy link
Copy Markdown
Member

Kobzol commented Mar 31, 2026

Looks like a tiny regression in debug and opt benchmarks. Not sure why would messing with const cause that. @Mark-Simulacrum Do you think it's worth it to do something about it? Only the cargo regressions were marked as significant.

@Mark-Simulacrum
Copy link
Copy Markdown
Member

It might be the const hacks causing slightly different inlining or something along those lines? I think it's probably not worth trying to dig into it given just one regression.

@Kobzol
Copy link
Copy Markdown
Member

Kobzol commented Mar 31, 2026

Ok, agreed.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Mar 31, 2026
@Lars-Schumann Lars-Schumann restored the const-step branch April 3, 2026 21:03
jhpratt added a commit to jhpratt/rust that referenced this pull request Apr 7, 2026
… r=jhpratt

constify `Step for NonZero<u*>`

Tracking Issue: rust-lang#42168

I missed the constification of `Step for NonZero<u*>` in the recent rust-lang#153821, so here they are.

Had to constify the `Clone` / `TrivialClone` impls along the way rust-lang#142757 .
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Apr 7, 2026
… r=jhpratt

constify `Step for NonZero<u*>`

Tracking Issue: rust-lang#42168

I missed the constification of `Step for NonZero<u*>` in the recent rust-lang#153821, so here they are.

Had to constify the `Clone` / `TrivialClone` impls along the way rust-lang#142757 .
rust-timer added a commit that referenced this pull request Apr 7, 2026
Rollup merge of #154825 - Lars-Schumann:non-zero-const-step, r=jhpratt

constify `Step for NonZero<u*>`

Tracking Issue: #42168

I missed the constification of `Step for NonZero<u*>` in the recent #153821, so here they are.

Had to constify the `Clone` / `TrivialClone` impls along the way #142757 .
github-actions bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Apr 8, 2026
constify `Step for NonZero<u*>`

Tracking Issue: rust-lang/rust#42168

I missed the constification of `Step for NonZero<u*>` in the recent rust-lang/rust#153821, so here they are.

Had to constify the `Clone` / `TrivialClone` impls along the way rust-lang/rust#142757 .
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. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants