-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Override Iterator::advance(_back)_by
for array::IntoIter
#91512
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: