inclusive Ranges: change end to last

[Qelxiros]

View all comments

Tracking issue: #125687
ACP: rust-lang/libs-team#511

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
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

[Qelxiros]

The above error isn't fixed by changing end to last, since rustc is built with beta std. I'm not sure how to fix this, since I'm not super familiar with the bootstrapping process.

[tgross35]

Can you try a rebase to poke CI?

Thom is off rotation
r? libs

[tgross35]

Come on rustbot, you've given me the last 5 rerolls
r? @jhpratt

[jhpratt]

pending the rebase to potentially get CI passing, @rustbot author

[rustbot]

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

[rustbot]

This PR was rebased onto a different master 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.

[Qelxiros]

The rebase doesn't seem to have changed anything. Let me know what else I can do to try to fix this.

@rustbot ready

[jhpratt]

Looks like there's a missed rename in compiler/rustc_index/src/idx.rs on line 134: https://github.com/rust-lang/rust/actions/runs/17433338416/job/49496772842?pr=144765#step:29:2015

There may be something else as well, but that's what's failing CI at the moment.

[Qelxiros]

To clarify the issue, the original failure occurs in stage1 -> stage2, when the compiler is using the new version of std with last. The new failure occurs in stage0 -> stage1, when the compiler doesn't know about last yet and expects end instead.

[jhpratt]

Ah, I didn't look at when it occurred. You'll need #[cfg(bootstrap)] and #[cfg(not(bootstrap))] in that case.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[Qelxiros]

Clippy context: I added sym::last to rustc, so it had to be removed from clippy.

[Qelxiros]

@rustbot ready

[jhpratt]

Nice work!

cc @rust-lang/lang for the new lang items. I'm not waiting for approval of that as it seems self-explanatory given the presence of lang items for other "new range" types.

@bors r+

[bors]

📌 Commit 8d0c07f has been approved by jhpratt

It is now in the queue for this repository.

[scottmcm]

cc @rust-lang/lang for the new lang items. I'm not waiting for approval of that as it seems self-explanatory given the presence of lang items for other "new range" types.

So long as it's just a lang-item for "the compiler needs to mention it" (rather than giving it special behaviour), then agreed no lang approval needed.

I assume here it's for expanding ..= to a struct literal of this type?

[camsteffen]

start and last are not complementary field names. first and last would be. Maybe start and endInclusive would be best (Kotlin uses this).

[JJia-Lisp]

Since RangeInclusive's field is being renamed to last, should RangeBounds::end_bound() also be renamed to last_bound() for consistency? @sendittothenewts

[sendittothenewts]

Since RangeInclusive's field is being renamed to last, should RangeBounds::end_bound() also be renamed to last_bound() for consistency? @sendittothenewts

No, because RangeBounds::end_bound still returns the end member of Range and RangeTo. Only the inclusive range types have had their upper bound renamed. Since the upper bounds of the inclusive and exclusive types intentionally have different names, RangeBounds must inevitably be inconsistent with at least one of them.

[JJia-Lisp]

Could we rename end_bound to something neutral — e.g., stop_bound — that works for both Range and RangeInclusive? @sendittothenewts