iter: extend step_by specialization to cover StepBy<RangeIter<{integer}>>

[Lfan-ke]

StepBy<Range<{integer}>> already has a fast path that converts the range
into a yield-count before iteration, avoiding per-step overflow checks and
enabling better loop structure for the optimizer. StepBy<RangeIter<{integer}>>
did not benefit from the same optimization even though RangeIter<T> is a thin
newtype wrapper around legacy::Range<T>.

Changes

• library/core/src/range/iter.rs: make RangeIter<A>.0 pub(crate) so the
  step_by adapter can access the inner legacy range's start/end fields.
• library/core/src/iter/adapters/step_by.rs: add spec_int_ranges_new! and
  spec_int_ranges_new_r! macros that mirror the existing spec_int_ranges! /
  spec_int_ranges_r! implementations. Forward specialization covers u8 u16 u32 u64 usize (pointer-width-gated for u32/u64); backward specialization is
  limited to u8 u16 usize since RangeIter<u32> / RangeIter<u64> do not
  implement ExactSizeIterator.
• library/coretests/tests/iter/adapters/step_by.rs: add
  test_step_by_new_range_iter covering forward, backward, and interleaved
  iteration via the new-range iterator.

Motivation

Fixes #157754. The inner loop for core::range::Range::from(0..n).into_iter().step_by(2) currently generates noticeably worse assembly than the equivalent (0..n).step_by(2) because specialization did not cover RangeIter.

r? libs

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @Darksonn (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• libs expanded to 12 candidates
• Random selection from 6 candidates

[Darksonn]

Would this work?

Suggested change

	fn spec_next(&mut self) -> Option<$t> {
	let step = <$t>::try_from(self.original_step().get()).unwrap_or(<$t>::MAX);
	let remaining = self.iter.0.end;
	if remaining > 0 {
	let val = self.iter.0.start;
	self.iter.0.start = val.wrapping_add(step);
	self.iter.0.end = remaining - 1;
	Some(val)
	} else {
	None
	}
	fn spec_next(&mut self) -> Option<$t> {
	self.legacy.spec_next()

View changes since the review

[Lfan-ke]

Good call on cutting the duplication. Direct delegation like self.legacy.spec_next() doesn't quite work here though: there's no inner StepBy<Range> to forward to. StepBy keeps the step state (step_minus_one, first_take) in the wrapper rather than in the iterator, so StepBy<RangeIter<T>> isn't a StepBy<Range<T>> plus a newtype, and since StepBy is repr(Rust) reinterpreting one as the other isn't sound.

Instead I unified the two macros. RangeIter<T> is a newtype over the same legacy Range<T> the existing specialization already drives, so I added a small AsLegacyRange accessor (identity for Range, &self.0 for RangeIter) and made spec_int_ranges! / spec_int_ranges_r! take the iterator type as a parameter. Both specializations now come from one macro body; the accessor is #[inline] and optimizes away, so the Range codegen is unchanged. That drops the duplicated spec_int_ranges_new! / _new_r! (~145 lines).

I also squashed the two commits and moved the issue reference out of the commit message into the PR description, per the earlier bot warning. Let me know if you'd prefer a different shape.

[Darksonn]

@rustbot author

View changes since this review

[Darksonn]

I think it'd be easier to read if we grouped them.

#[cfg(target_pointer_width = "64")]
mod step_by_spec {
    spec_int_ranges!(Range; u8 u16 u32 u64 usize);
    spec_int_ranges!(RangeIter; u8 u16 u32 u64 usize);
    spec_int_ranges_r!(Range; u8 u16 u32 usize);
    spec_int_ranges_r!(RangeIter; u8 u16 usize);
}

#[cfg(target_pointer_width = "32")]
mod step_by_spec {
    ...
}

#[cfg(target_pointer_width = "16")]
mod step_by_spec {
    ...
}

[Darksonn]

Why is u32 missing here?

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Lfan-ke]

Grouped the invocations into a per-width mod step_by_spec as suggested.

On the missing u32: the backward (_r) specialization requires ExactSizeIterator, and RangeIter implements it more narrowly than the legacy Range. range_exact_iter_impl! in core::range::iter only covers usize u8 u16 isize i8 i16, so RangeIter<u32> is not ExactSizeIterator even on 64-bit, whereas Range<u32> is. That's why u32 appears in spec_int_ranges_r!(Range; ...) but not in spec_int_ranges_r!(RangeIter; ...). Forward specialization has no such requirement, so both cover u32/u64. I moved this explanation into the comment above the block.

Built and ran library/coretests step_by tests locally; all pass.

[Darksonn]

@bors r+

View changes since this review

[rust-bors]

📌 Commit dcc9c46 has been approved by Darksonn

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

Reason for tree closure: spurious failures