Rollup of 11 pull requests #49406
Merged
Rollup of 11 pull requests #49406
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
kennytm
commented
Mar 27, 2018
•
kennytm
commented
- Successful merges: Add slice::sort_by_cached_key as a memoised sort_by_key #48639, Propose a variant if it is an enum for E0599 #49223, Fix impl assoc constant link not working #49333, Fix pretty-printing for raw identifiers #49369, Add is_whitespace and is_alphanumeric to str. #49381, libsyntax: Remove obsolete.rs #49395, Fix diagnostic colors on Windows 10 console. #49399, Add missing '?' to format grammar. #49401, Update compiler-rt with fix for 32bit iOS ARM #49417, Introduce trait engine #49202, Update CONTRIBUTING.md #49426
- Failed merges:
The other methods from `UnicodeStr` are already stable inherent methods on str, but these have not been included.
This updates termcolor to pick up BurntSushi/ripgrep#867. Fixes rust-lang#49322.
Add slice::sort_by_cached_key as a memoised sort_by_key At present, `slice::sort_by_key` calls its key function twice for each comparison that is made. When the key function is expensive (which can often be the case when `sort_by_key` is chosen over `sort_by`), this can lead to very suboptimal behaviour. To address this, I've introduced a new slice method, `sort_by_cached_key`, which has identical semantic behaviour to `sort_by_key`, except that it guarantees the key function will only be called once per element. Where there are `n` elements and the key function is `O(m)`: - `slice::sort_by_cached_key` time complexity is `O(m n log m n)`, compared to `slice::sort_by_key`'s `O(m n + n log n)`. - `slice::sort_by_cached_key` space complexity remains at `O(n + m)`. (Technically, it now reserves a slice of size `n`, whereas before it reserved a slice of size `n/2`.) `slice::sort_unstable_by_key` has not been given an analogue, as it is important that unstable sorts are in-place, which is not a property that is guaranteed here. However, this also means that `slice::sort_unstable_by_key` is likely to be slower than `slice::sort_by_cached_key` when the key function does not have negligible complexity. We might want to explore this trade-off further in the future. Benchmarks (for a vector of 100 `i32`s): ``` # Lexicographic: `|x| x.to_string()` test bench_sort_by_key ... bench: 112,638 ns/iter (+/- 19,563) test bench_sort_by_cached_key ... bench: 15,038 ns/iter (+/- 4,814) # Identity: `|x| *x` test bench_sort_by_key ... bench: 1,346 ns/iter (+/- 238) test bench_sort_by_cached_key ... bench: 1,839 ns/iter (+/- 765) # Power: `|x| x.pow(31)` test bench_sort_by_key ... bench: 3,624 ns/iter (+/- 738) test bench_sort_by_cached_key ... bench: 1,997 ns/iter (+/- 311) # Abs: `|x| x.abs()` test bench_sort_by_key ... bench: 1,546 ns/iter (+/- 174) test bench_sort_by_cached_key ... bench: 1,668 ns/iter (+/- 790) ``` (So it seems functions that are single operations do perform slightly worse with this method, but for pretty much any more complex key, you're better off with this optimisation.) I've definitely found myself using expensive keys in the past and wishing this optimisation was made (e.g. for rust-lang#47415). This feels like both desirable and expected behaviour, at the small cost of slightly more stack allocation and minute degradation in performance for extremely trivial keys. Resolves rust-lang#34447.
…E0599, r=cramertj Propose a variant if it is an enum for E0599 Fixes rust-lang#49192.
…QuietMisdreavus Fix impl assoc constant link not working Fixes rust-lang#49323. r? @QuietMisdreavus
Fix pretty-printing for raw identifiers
Add is_whitespace and is_alphanumeric to str. The other methods from `UnicodeStr` are already stable inherent methods on str, but these have not been included. r? @SimonSapin
libsyntax: Remove obsolete.rs This little piece of infra is obsolete (ha-ha) and is unlikely to be used in the future, even if new obsolete syntax appears.
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ p=8 |
|
📌 Commit b4bc2b0 has been approved by |
bors
added
S-waiting-on-bors
Update compiler-rt with fix for 32bit iOS ARM
|
📌 Commit 0873974 has been approved by |
The current link is a 404, just link to the main repo page
Add back 1.24.1 release notes
Update CONTRIBUTING.md The current link is a 404, just link to the main repo page
|
📌 Commit 605ea7c has been approved by |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
@bors retry A macOS job is stuck at downloading the |
bors
added
S-waiting-on-bors
|
☀️ Test successful - status-appveyor, status-travis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.