-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Rollup of 9 pull requests #120136
Rollup of 9 pull requests #120136
Conversation
These methods currently return `(last_chunk, preceding_slice)`, which matches the existing `split_x` methods that remove one item. Change these to instead return `(preceding_slice, last_chunk)` which matches string split methods, should be more intuitive, and will allow for consistency with methods that split more items.
Clarify that these functions return array references. Also change from doing `as` casting to using the less misuseable `.cast()`.
The functionality of these methods from `split_array` has been absorbed by the `slice_first_last_chunk` feature. This only affects the methods on slices, not those with the same name that are implemented on array types. Also adjusts testing to reflect this change.
… putting an anchor to their left side
This stabilizes all methods under `slice_first_last_chunk`. Additionally, it const stabilizes the non-mut functions and moves the `_mut` functions under `const_slice_first_last_chunk`. These are blocked on `const_mut_refs`. As part of this change, `slice_split_at_unchecked` was marked const-stable for internal use (but not fully stable).
The changelog can be found here: https://docs.rs/libloading/latest/libloading/changelog/r0_8_0/index.html
We had reached a point where the shenanigans about omitting empty arms are unnecessary.
The advantage of this is that it does not need to be assigned to a variable to be used in a `Context` creation, which is the most common thing to want to do with a noop waker. If an owned noop waker is desired, it can be created by cloning, but the reverse is harder. Alternatively, both versions could be provided, like `futures::task::noop_waker()` and `futures::task::noop_waker_ref()`, but that seems to me to be API clutter for a very small benefit, whereas having the `&'static` reference available is a large benefit. Previous discussion on the tracking issue starting here: rust-lang#98286 (comment)
`Waker::noop()` now returns a `&'static Waker` reference, so it can be passed directly to `Context` creation with no temporary lifetime issue.
A-diagnostics is already labeled correctly thanks to the template and there usually isn't much to do on those issues, so it's fine to just add them to the pile.
Stabilize `slice_first_last_chunk` This PR does a few different things based around stabilizing `slice_first_last_chunk`. They are split up so this PR can be by-commit reviewed, I can move parts to a separate PR if desired. This feature provides a very elegant API to extract arrays from either end of a slice, such as for parsing integers from binary data. ## Stabilize `slice_first_last_chunk` ACP: rust-lang/libs-team#69 Implementation: rust-lang#90091 Tracking issue: rust-lang#111774 This stabilizes the functionality from rust-lang#111774: ```rust impl [T] { pub const fn first_chunk<const N: usize>(&self) -> Option<&[T; N]>; pub fn first_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>; pub const fn last_chunk<const N: usize>(&self) -> Option<&[T; N]>; pub fn last_chunk_mut<const N: usize>(&mut self) -> Option<&mut [T; N]>; pub const fn split_first_chunk<const N: usize>(&self) -> Option<(&[T; N], &[T])>; pub fn split_first_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T; N], &mut [T])>; pub const fn split_last_chunk<const N: usize>(&self) -> Option<(&[T], &[T; N])>; pub fn split_last_chunk_mut<const N: usize>(&mut self) -> Option<(&mut [T], &mut [T; N])>; } ``` Const stabilization is included for all non-mut methods, which are blocked on `const_mut_refs`. This change includes marking the trivial function `slice_split_at_unchecked` const-stable for internal use (but not fully stable). ## Remove `split_array` slice methods Tracking issue: rust-lang#90091 Implementation: rust-lang#83233 (review) This PR also removes the following unstable methods from the `split_array` feature, rust-lang#90091: ```rust impl<T> [T] { pub fn split_array_ref<const N: usize>(&self) -> (&[T; N], &[T]); pub fn split_array_mut<const N: usize>(&mut self) -> (&mut [T; N], &mut [T]); pub fn rsplit_array_ref<const N: usize>(&self) -> (&[T], &[T; N]); pub fn rsplit_array_mut<const N: usize>(&mut self) -> (&mut [T], &mut [T; N]); } ``` This is done because discussion at rust-lang#90091 and its implementation PR indicate a strong preference for nonpanicking APIs that return `Option`. The only difference between functions under the `split_array` and `slice_first_last_chunk` features is `Option` vs. panic, so remove the duplicates as part of this stabilization. This does not affect the array methods from `split_array`. We will want to revisit these once `generic_const_exprs` is further along. ## Reverse order of return tuple for `split_last_chunk{,_mut}` An unresolved question for rust-lang#111774 is whether to return `(preceding_slice, last_chunk)` (`(&[T], &[T; N])`) or the reverse (`(&[T; N], &[T])`), from `split_last_chunk` and `split_last_chunk_mut`. It is currently implemented as `(last_chunk, preceding_slice)` which matches `split_last -> (&T, &[T])`. The first commit changes these to `(&[T], &[T; N])` for these reasons: - More consistent with other splitting methods that return multiple values: `str::rsplit_once`, `slice::split_at{,_mut}`, `slice::align_to` all return tuples with the items in order - More intuitive (arguably opinion, but it is consistent with other language elements like pattern matching `let [a, b, rest @ ..] ...` - If we ever added a varidic way to obtain multiple chunks, it would likely return something in order: `.split_many_last::<(2, 4)>() -> (&[T], &[T; 2], &[T; 4])` - It is the ordering used in the `rsplit_array` methods I think the inconsistency with `split_last` could be acceptable in this case, since for `split_last` the scalar `&T` doesn't have any internal order to maintain with the other items. ## Unresolved questions Do we want to reserve the same names on `[u8; N]` to avoid inference confusion? rust-lang#117561 (comment) --- `slice_first_last_chunk` has only been around since early 2023, but `split_array` has been around since 2021. `@rustbot` label -T-libs +T-libs-api -T-libs +needs-fcp cc `@rust-lang/wg-const-eval,` `@scottmcm` who raised this topic, `@clarfonthey` implementer of `slice_first_last_chunk` `@jethrogb` implementer of `split_array` Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Stabilizing.20array-from-slice.20*something*.3F Fixes: rust-lang#111774
…r=notriddle [rustdoc] Allows links in headings Reopening of rust-lang#94360. # Explanations Rustdoc currently doesn't follow the markdown spec on headings: we don't allow links in them. So instead of having headings linking to themselves, this PR generates an anchor on the left side like this: ![image](https://github.com/rust-lang/rust/assets/3050060/a118a7e9-5ef8-4d07-914f-46defc3245c3) <details> <summary>previous version</summary> ![image](https://github.com/rust-lang/rust/assets/3050060/c34fa844-9cd4-47dc-bb51-b37f5f66afee) </details> Having the anchor always displayed allows for mobile devices users to be able to have a link to the anchor. The different color used for the anchor itself is the same as links so people notice when looking at it that they can click on it. You can test it [here](https://rustdoc.crud.net/imperio/links-in-headings/std/index.html). cc `@camelid` r? `@notriddle`
…use-somewhat, r=bjorn3 Format sources into the error message when loading codegen backends cc rust-lang/rustc_codegen_cranelift#1447 cc `@bjorn3`
…compiler-errors Exhaustiveness: simplify empty pattern logic The logic that handles empty patterns had gotten quite convoluted. This PR simplifies it a lot. I tried to make the logic as easy as possible to follow; this only does logically equivalent changes. The first commit is a drive-by comment clarification that was requested after another PR a while back. r? `@compiler-errors`
@bors r+ rollup=never p=10 |
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#117561 (Stabilize `slice_first_last_chunk`) - rust-lang#117662 ([rustdoc] Allows links in headings) - rust-lang#119815 (Format sources into the error message when loading codegen backends) - rust-lang#119835 (Exhaustiveness: simplify empty pattern logic) - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.) - rust-lang#120009 (never_patterns: typecheck never patterns) - rust-lang#120122 (Don't add needs-triage to A-diagnostics) - rust-lang#120126 (Suggest `.swap()` when encountering conflicting borrows from `mem::swap` on a slice) - rust-lang#120134 (Restrict access to the private field of newtype indexes) Failed merges: - rust-lang#119968 (Remove unused/unnecessary features) r? `@ghost` `@rustbot` modify labels: rollup
💥 Test timed out |
@bors retry (timeout, no failures otherwise) |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 0547c41f90 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (128148d): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 663.278s -> 665.078s (0.27%) |
Successful merges:
slice_first_last_chunk
#117561 (Stabilizeslice_first_last_chunk
)Waker::noop()
fromWaker
to&Waker
. #119984 (Change return type of unstableWaker::noop()
fromWaker
to&Waker
.).swap()
when encountering conflicting borrows frommem::swap
on a slice #120126 (Suggest.swap()
when encountering conflicting borrows frommem::swap
on a slice)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup