Skip to content

Conversation

@hkBst
Copy link
Member

@hkBst hkBst commented Sep 11, 2025

No description provided.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 11, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 11, 2025

r? @scottmcm

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

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@hkBst
Copy link
Member Author

hkBst commented Oct 10, 2025

r? libs

@rustbot rustbot assigned ibraheemdev and unassigned scottmcm Oct 10, 2025
@ibraheemdev
Copy link
Member

Going to pass this one along. r? libs

@rustbot rustbot assigned joboet and unassigned ibraheemdev Oct 22, 2025
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 31, 2025
@rustbot

This comment has been minimized.

@hkBst
Copy link
Member Author

hkBst commented Nov 1, 2025

@rustbot ready

Perhaps a perf run to see if I haven't regressed anything unwittingly?

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 1, 2025
// SAFETY: Nothing else points to or will point to the contents of this slice.
Some(unsafe { &mut *head })
}
// SAFETY: we have `&mut self`, so are allowed to temporarily materialize a mut slice
Copy link
Member

Choose a reason for hiding this comment

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

I'd add that next must not be called if __get_unchecked was called, so invalidating previously returned items does not conflict with TrustedRandomAccess.

Copy link
Member Author

Choose a reason for hiding this comment

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

While that is true, I don't see how this particular next method is special in that regard. So would you then like all next methods of iterators that impl TrustedRandomAccess to get such a comment?

@rustbot
Copy link
Collaborator

rustbot commented Nov 4, 2025

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.

@hkBst
Copy link
Member Author

hkBst commented Nov 4, 2025

@joboet Thanks for reviewing so far; your comments have been very helpful!

I've removed all uses of overflowing_* and also switched all remaining conditions like if n >= len { code } else { code that needs the condition to be correct } to if n < len { code that needs the condition to be correct } else { code }.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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