-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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 #128927
Rollup of 8 pull requests #128927
Conversation
The new sort implementations have the ability to detect Ord violations in many cases. This commit improves the message in a way that should help users realize what went wrong in their program.
…ble* - Move panic information into # Panics section - Fix mentions of T: Ord that should be compare - Add missing information
- Use if the implementation of [`Ord`] for `T` language - Link to total order wiki page - Rework total order help and examples - Improve language to be more precise and less prone to misunderstandings. - Fix usage of `sort_unstable_by` in `sort_by` example - Fix missing author mention - Use more consistent example input for sort - Use more idiomatic assert_eq! in examples - Use more natural "comparison function" language instead of "comparator function"
"when to complex" should obviously be "too complex"
Accurately refer to assoc fn without receiver as assoc fn instead of methods. Add `AssocItem::descr` method to centralize where we call methods and associated functions.
…elp, r=workingjubilee Improve `Ord` violation help Recent experience in rust-lang#128083 showed that the panic message when an Ord violation is detected by the new sort implementations can be confusing. So this PR aims to improve it, together with minor bug fixes in the doc comments for sort*, sort_unstable* and select_nth_unstable*. Is it possible to get these changes into the 1.81 release? It doesn't change behavior and would greatly help when users encounter this panic for the first time, which they may after upgrading to 1.81. Tagging `@orlp`
run-make: explaing why fmt-write-bloat is ignore-windows The trouble here is that libc doesn't exist on Windows. Well it kinda does but it isn't called that so we substitute a name that works. Ideally finding necessary libs for the platform would be done at a higher level but until then this should work. try-job: x86_64-msvc try-job: x86_64-mingw try-job: i686-msvc try-job: i686-mingw
rustdoc-json-types `Discriminant`: fix typo "when to complex" should obviously be "too complex"
…eyouxu gitignore: Add Zed and Helix editors Just adding two extra code editors to .gitignore. Reference: https://helix-editor.com/ https://zed.dev/
…lifetime-bounds, r=compiler-errors diagnostics: do not warn when a lifetime bound infers itself Fixes rust-lang#119228
Fix dump-ice-to-disk for RUSTC_ICE=0 users Before this change, the test fails if you run it with `RUSTC_ICE=0`.
Differentiate between methods and associated functions in diagnostics Accurately refer to assoc fn without receiver as assoc fn instead of methods. Add `AssocItem::descr` method to centralize where we call methods and associated functions.
…s, r=fmease [rustdoc] Stop showing impl items for negative impls Fixes rust-lang#128799. As discussed with `@fmease,` they have a broader patch in progress, so this (small) PR will at least allow for them to have a regression test. :) r? `@fmease`
@bors r+ p=8 rollup=never |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 8291d68d92 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (04ba50e): 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)Results (primary 2.6%, secondary -4.7%)This 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.
CyclesResults (primary 1.0%, secondary -0.4%)This 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.
Binary sizeResults (secondary 0.0%)This 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.
Bootstrap: 757.146s -> 758.54s (0.18%) |
Successful merges:
Ord
violation help #128273 (ImproveOrd
violation help)Discriminant
: fix typo #128903 (rustdoc-json-typesDiscriminant
: fix typo)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup