Add `<[[T; N]]>::flatten{_mut}` by Cyborus04 · Pull Request #95579 · rust-...
source link: https://github.com/rust-lang/rust/pull/95579
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
New issue
Add <[[T; N]]>::flatten{_mut}
#95579
Conversation
Adds flatten to convert &[[T; N]] to &[T] (and flatten_mut for &mut [[T; N]] to &mut [T])
added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @yaahc (or someone else) soon.
Please see the contribution instructions for more information.
added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label
Since it's now (#95016) agreed to be sound, consider adding Vec::flatten to go with these as well.
(Or maybe it should be into_flattened or something to not shadow the slice method.)
This comment has been minimized.
r? @scottmcm
This comment has been minimized.
This comment has been minimized.
Wow, is there really no usage of unchecked_* math in alloc? That can't be right...
Wow, is there really no usage of unchecked_* math in alloc? That can't be right...
It doesn't surprise me, really. As the feature explanation says, it's a niche optimization path where it's extremely rare for it to be actually relevant. And the building blocks that are foundational enough to use it tend to be in core.
Oh, I missed that before I pushed that commit. Should I just used normal * multiplication then?
This comment has been minimized.
Oh, I missed that before I pushed that commit. Should I just used normal * multiplication then?
Naw, it's fine. It's plausibly helpful for optimization, since otherwise LLVM doesn't know that the slice didn't get shorter.
Another use case is to convert &[[T; N]; M] to &[T; N * M]. That's a case of array reshaping in general.
added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
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
This comment has been minimized.
🤦🏻♂️
This comment has been minimized.
This comment has been minimized.
oh uh messed this one up a bit
That works, but is it okay to so directly expose an unstable feature?
As far as I know we don't want to use anything that's still incomplete_features in the bootstrap compiler. Unstable is fine when it's decently-baked, but if compiler says it's incomplete, we don't use it in libs.
I found a few more nits, and I have one extra request: Can you add #[should_panic(expect = "... tests for the overflow cases, please?
So something like
#[test]
#[should_panic(expect = "vec len overflow")]
fn vec_into_flattened_panics_for_capacity_overflow() {
let n = 1 << (usize::BITS / 2);
let _ = vec![[(); n]; n].into_flattened();
}which would probably go in https://github.com/rust-lang/rust/blob/master/library/alloc/tests/vec.rs
And analogous ones for the two slice methods.
When you're done, please comment @rustbot ready to update the tags accordingly.
This comment has been minimized.
wait i put it in the wrong file 
What do I do about the feature flag issue? There's other tests that use unstable features without any #[feature(...)] attributes
I think you need to allow the new feature in the tests library, like all of these ones
#![feature(allocator_api)]
#![feature(alloc_layout_extra)]
#![feature(assert_matches)]
#![feature(box_syntax)]
#![feature(cow_is_borrowed)]
#![feature(const_box)]
#![feature(const_convert)]
#![feature(const_cow_is_borrowed)]
#![feature(const_heap)]
#![feature(const_intrinsic_copy)]
#![feature(const_mut_refs)]
#![feature(const_nonnull_slice_from_raw_parts)]
#![feature(const_ptr_write)]
#![feature(const_try)]
#![feature(core_intrinsics)]
#![feature(drain_filter)]
#![feature(exact_size_is_empty)]
#![feature(new_uninit)]
#![feature(pattern)]
#![feature(trusted_len)]
#![feature(try_reserve_kind)]
#![feature(unboxed_closures)]
#![feature(associated_type_bounds)]
#![feature(binary_heap_into_iter_sorted)]
#![feature(binary_heap_drain_sorted)]
#![feature(slice_ptr_get)]
#![feature(binary_heap_retain)]
#![feature(binary_heap_as_slice)]
#![feature(inplace_iteration)]
#![feature(iter_advance_by)]
#![feature(round_char_boundary)]
#![feature(slice_group_by)]
#![feature(slice_partition_dedup)]
#![feature(string_remove_matches)]
#![feature(const_btree_new)]
#![feature(const_default_impls)]
#![feature(const_trait_impl)]
#![feature(const_str_from_utf8)]
#![feature(nonnull_slice_from_raw_parts)]
#![feature(panic_update_hook)]
This comment has been minimized.
This comment has been minimized.
Let's see if it'll just let me commit these suggestions...
Ohhh, thank you! I've been confused about this all day, glad it's finally solved 
uh oh i think i destroyed your commit by accident, sorry. forgot to pull first
Looks good! Thanks for your perseverance through all the hiccups.
@bors r+
Commit 06788fd has been approved by scottmcm
added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Congrats on your first PR landing, @Cyborus04!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
None yet
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK