-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 8 pull requests #102265
Rollup of 8 pull requests #102265
Conversation
In cases where the nth element is not unique within the slice, it is not correct to say that the values in the returned triplet include ones for "all elements" less/greater than that at the given index: indeed one (or more) such values would then laso contain values equal to that at the given index. The text proposed here clarifies exactly what is returned, but in so doing it is also documenting an implementation detail that previously wasn't detailed: namely that the return slices are slices into the reordered slice. I don't think this can be contentious, because the lifetimes of those returned slices are bound to that of the original (now reordered) slice—so there really isn't any other reasonable implementation that could have this behaviour; but nevertheless it's probably best if @rust-lang/libs-api give it a nod? Fixes rust-lang#97982 r? m-ou-se @rustbot label +A-docs C-bug +T-libs-api
Co-authored-by: Andreas Jonson <[email protected]>
Clarify `[T]::select_nth_unstable*` return values In cases where the nth element is not unique within the slice, it is not correct to say that the values in the returned triplet include ones for "all elements" less/greater than that at the given index: indeed one (or more) such values would then also contain elements equal to that at the given index. The text proposed here clarifies exactly what is returned, but in so doing it is also documenting an implementation detail that previously wasn't detailed: namely that the returned slices are slices into the reordered slice. I don't think this can be contentious, because the lifetimes of those returned slices are bound to that of the original (now reordered) slice—so there really isn't any other reasonable implementation that could have this behaviour; but nevertheless it's probably best if `@rust-lang/libs-api` give it a nod? Fixes rust-lang#97982 r? `@m-ou-se` `@rustbot` label +A-docs +C-bug +T-libs-api -T-libs
…move-place-sugg, r=cjgillot Look at move place's type when suggesting mutable reborrow Not sure why we are looking at the use site's ty instead of the move site's ty in order to suggest reborrowing the move site, but it was suppressing a perfectly valid reborrow suggestion. r? `@estebank` who i think touched this last in 520461f, though that was quite a while ago so feel free to reassign.
…, r=fee1-dead Constify slice.split_at_mut(_unchecked) Tracking Issue: [Tracking Issue for const_slice_split_at_mut](rust-lang#101804) Feature gate: `#![feature(const_slice_split_at_mut)]` Still requires const_mut_refs to be actually used, but this feature removes the need to manually re implement these functions in a user crate.
Remove support for legacy PM This removes support for optimizing with LLVM's legacy pass manager, as well as the unstable `-Znew-llvm-pass-manager` option. We have been defaulting to the new PM since LLVM 13 (except for s390x that waited for 14), and LLVM 15 removed support altogether. The only place we still use the legacy PM is for writing the output file, just like `llc` does. cc rust-lang#74705 r? ``@nikic``
…op, r=oli-obk Note the type when unable to drop values in compile time
…s, r=fee1-dead Constify Default impl's for Arrays and Tuples. Allows to create arrays and tuples in const Context using the ~const Default implementation of the inner type.
…e1-dead Constify cmp_min_max_by. Constifies `core::cmp::{min, max}_by[_key]` behind the `const_cmp` rust-lang#92391 feature gate, using `const_closure`.
Type-annotate and simplify documentation of Option::unwrap_or_default Part of rust-lang#100054
@bors p=8 r+ |
@bors rollup=never |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 4652f5eb25 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (17e8752): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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.
CyclesResultsThis 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.
Footnotes |
Successful merges:
[T]::select_nth_unstable*
return values #98111 (Clarify[T]::select_nth_unstable*
return values)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup