-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Increment self.index
before calling `Iterator::self.a.__iterator_ge…
#81741
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Increment self.index
before calling `Iterator::self.a.__iterator_ge…
#81741
Conversation
…t_unchecked` in `Zip` `TrustedRandomAccess` specialization Otherwise if `Iterator::self.a.__iterator_get_unchecked` panics the index would not have been incremented yet and another call to `Iterator::next` would read from the same index again, which is not allowed according to the API contract of `TrustedRandomAccess` for `!Clone`. Fixes rust-lang#81740
r? @KodrAus (rust-highfive has picked a reviewer for you, use r? to override) |
@bors r+ |
📌 Commit 86a4b27 has been approved by |
…pecialization-panic-safety, r=KodrAus Increment `self.index` before calling `Iterator::self.a.__iterator_ge… …`t_unchecked` in `Zip` `TrustedRandomAccess` specialization Otherwise if `Iterator::self.a.__iterator_get_unchecked` panics the index would not have been incremented yet and another call to `Iterator::next` would read from the same index again, which is not allowed according to the API contract of `TrustedRandomAccess` for `!Clone`. Fixes rust-lang#81740
…pecialization-panic-safety, r=KodrAus Increment `self.index` before calling `Iterator::self.a.__iterator_ge… …`t_unchecked` in `Zip` `TrustedRandomAccess` specialization Otherwise if `Iterator::self.a.__iterator_get_unchecked` panics the index would not have been incremented yet and another call to `Iterator::next` would read from the same index again, which is not allowed according to the API contract of `TrustedRandomAccess` for `!Clone`. Fixes rust-lang#81740
Rollup of 10 pull requests Successful merges: - rust-lang#79775 (Fix injected errors when running doctests on a crate named after a keyword) - rust-lang#81012 (Stabilize the partition_point feature) - rust-lang#81479 (Allow casting mut array ref to mut ptr) - rust-lang#81506 (HWAddressSanitizer support) - rust-lang#81741 (Increment `self.index` before calling `Iterator::self.a.__iterator_ge…) - rust-lang#81850 (use RWlock when accessing os::env) - rust-lang#81911 (GAT/const_generics: Allow with_opt_const_param to return GAT param def_id) - rust-lang#82022 (Push a `char` instead of a `str` with len one into a String) - rust-lang#82023 (Remove unnecessary lint allow attrs on example) - rust-lang#82030 (Use `Iterator::all` instead of open-coding it) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Is it worth (or even possible) to add a testcase for this? I run the libcore test site in Miri every day, so it makes sense to have a test that "used to trigger UB" and thereby ensure that it does not do that any more. Currently the test suite passes -- testing an iterator properly is hard, and I guess the test suite simply does not hit the code paths that cause UB. |
@RalfJung That would make sense but should probably wait until the other recent issues with the I'll try to not forget and do that once those are fixed. |
I was specifically thinking of #82289 |
…
t_unchecked
inZip
TrustedRandomAccess
specializationOtherwise if
Iterator::self.a.__iterator_get_unchecked
panics theindex would not have been incremented yet and another call to
Iterator::next
would read from the same index again, which is notallowed according to the API contract of
TrustedRandomAccess
for!Clone
.Fixes #81740