-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Override Iterator::advance(_back)_by
for array::IntoIter
#91512
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
Conversation
Because I happened to notice that `nth` is currently getting codegen'd as a loop even for `Copy` types: <https://rust.godbolt.org/z/fPqv7Gvs7>
(rust-highfive has picked a reviewer for you, use r? to override) |
unsafe { | ||
let slice = self.data.get_unchecked_mut(range_to_drop); | ||
ptr::drop_in_place(MaybeUninit::slice_assume_init_mut(slice)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tangent: These dances seem a bit unergonomic and repeated in several places.
ptr::drop_in_place
can take a *mut [T]
(fat pointer), so for unsafe code it would be great if we had something like [T].as_slice_ptr().get_unchecked(range).cast()
then we wouldn't have to refer to use those unwieldy associated methods on MaybeUninit
since we're operating on pointers anyway. Generally there's a lack of helpers to work with *mut/const [T]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, there's assume_init_drop
but no slice version of that, so I guess there could be assume_init_drop_range
like there's slice_assume_init_mut
and such -- one could always pass ..
to drop everything easily.
Don't think I'll do that in this PR, though.
@bors r+ rollup=never |
📌 Commit eb846db has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ce0f7ba): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Because I happened to notice that
nth
is currently getting codegen'd as a loop even forCopy
types: https://rust.godbolt.org/z/fPqv7Gvs7LLVM before and after
Rust:
Current nightly:
With this PR: