Rollup of 12 pull requests #39565
Closed
Rollup of 12 pull requests #39565
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
Only set the flags if they differ from what the OS reported, use `FIONBIO` to atomically set the non-blocking IO flag on Linux.
We introduced the unadjusted ABI to work around wrong (buggy) ABI expectations by LLVM on Windows [1]. Therefore, it should be solely used on Windows and not on other platforms, like right now is the case. [1]: see this comment for details rust-lang#38482 (comment)
Instead of directly creating a 'DIGlobalVariable', we now have to create a 'DIGlobalVariableExpression' which itself contains a reference to a 'DIGlobalVariable'. This is a straightforward change. In the future, we should rename 'DIGlobalVariable' in the FFI bindings, assuming we will only refer to 'DIGlobalVariableExpression' and not 'DIGlobalVariable'.
First, get rid of some bound checks. Second, instead of comparing by ternary `compare` function, use a binary function testing whether an element is less than some other element. This apparently makes it easier for the compiler to reason about the code. Benchmark: ``` name before ns/iter after ns/iter diff ns/iter diff % slice::bench::sort_large_ascending 8,969 (8919 MB/s) 7,410 (10796 MB/s) -1,559 -17.38% slice::bench::sort_large_big_ascending 355,640 (3599 MB/s) 359,137 (3564 MB/s) 3,497 0.98% slice::bench::sort_large_big_descending 427,112 (2996 MB/s) 424,721 (3013 MB/s) -2,391 -0.56% slice::bench::sort_large_big_random 2,207,799 (579 MB/s) 2,138,804 (598 MB/s) -68,995 -3.13% slice::bench::sort_large_descending 13,694 (5841 MB/s) 13,514 (5919 MB/s) -180 -1.31% slice::bench::sort_large_mostly_ascending 239,697 (333 MB/s) 203,542 (393 MB/s) -36,155 -15.08% slice::bench::sort_large_mostly_descending 270,102 (296 MB/s) 234,263 (341 MB/s) -35,839 -13.27% slice::bench::sort_large_random 513,406 (155 MB/s) 470,084 (170 MB/s) -43,322 -8.44% slice::bench::sort_large_random_expensive 23,650,321 (3 MB/s) 23,675,098 (3 MB/s) 24,777 0.10% slice::bench::sort_medium_ascending 143 (5594 MB/s) 132 (6060 MB/s) -11 -7.69% slice::bench::sort_medium_descending 197 (4060 MB/s) 188 (4255 MB/s) -9 -4.57% slice::bench::sort_medium_random 3,358 (238 MB/s) 3,271 (244 MB/s) -87 -2.59% slice::bench::sort_small_ascending 32 (2500 MB/s) 32 (2500 MB/s) 0 0.00% slice::bench::sort_small_big_ascending 97 (13195 MB/s) 97 (13195 MB/s) 0 0.00% slice::bench::sort_small_big_descending 247 (5182 MB/s) 249 (5140 MB/s) 2 0.81% slice::bench::sort_small_big_random 502 (2549 MB/s) 498 (2570 MB/s) -4 -0.80% slice::bench::sort_small_descending 55 (1454 MB/s) 61 (1311 MB/s) 6 10.91% slice::bench::sort_small_random 358 (223 MB/s) 356 (224 MB/s) -2 -0.56% ```
Before, the `count` would be copied into the closure and could potentially be optimized way. This change ensures it's borrowed by closure and finally consumed by `test::black_box`.
Thanks to @nagisa for pointing these out (rust-lang#38473 (comment)).
rename other than copy/remove
…gisa Don't use "unadjusted" ABI on non windows platforms We introduced the unadjusted ABI to work around wrong (buggy) ABI expectations by LLVM on Windows [1]. Therefore, it should be solely used on Windows and not on other platforms, like right now is the case. [1]: see this comment for details rust-lang#38482 (comment)
liballoc_jemalloc: fix linking with system library Fix rust-lang#39215
…eebsd, r=alexcrichton Support aarch64-unknown-freebsd
…hton Extract libcore benchmarks to a separate folder Fix rust-lang#39484 r? @alexcrichton since you seem to know about this :) Thanks!
libbacktrace: Fix uninitialized variable Fixes rust-lang#39468
…chton
Use less syscalls in `FileDesc::set_{nonblocking,cloexec}`
Only set the flags if they differ from what the OS reported, use
`FIONBIO` to atomically set the non-blocking IO flag on Linux.
More snap cleanup r? @alexcrichton
…alexcrichton [LLVM 4.0] Support a debug info API change for LLVM 4.0 Instead of directly creating a `DIGlobalVariable`, we now have to create a `DIGlobalVariableExpression` which itself contains a reference to a 'DIGlobalVariable'. This is a straightforward change. In the future, we should rename `DIGlobalVariable` in the FFI bindings, assuming we will only refer to `DIGlobalVariableExpression` and not `DIGlobalVariable`.
ignore more gdb versions with buggy rust support This extends the versions of gdb which were ignored in rust-lang#39039. While just ignoring gdb versions up to 7.12.1 would have been sufficient for now, I believe (after consulting https://sourceware.org/gdb/wiki/Internals%20Versions) that ignoring versions up to 7.12.9 will prevent the tests failing again for 7.12.2, etc. while still running all tests for the development versions of gdb (which will be >= 7.12.10 as far as I can tell). This should fix rust-lang#39522. cc @Manishearth, @michaelwoerister, rust-lang#38948
…alexcrichton Slightly optimize slice::sort First, get rid of some bound checks. Second, instead of comparing by ternary `compare` function, use a binary function testing whether an element is less than some other element. This apparently makes it easier for the compiler to reason about the code. I've noticed the same effect with [pdqsort](https://github.com/stjepang/pdqsort) crate. Benchmark: ``` name before ns/iter after ns/iter diff ns/iter diff % slice::bench::sort_large_ascending 8,969 (8919 MB/s) 7,410 (10796 MB/s) -1,559 -17.38% slice::bench::sort_large_big_ascending 355,640 (3599 MB/s) 359,137 (3564 MB/s) 3,497 0.98% slice::bench::sort_large_big_descending 427,112 (2996 MB/s) 424,721 (3013 MB/s) -2,391 -0.56% slice::bench::sort_large_big_random 2,207,799 (579 MB/s) 2,138,804 (598 MB/s) -68,995 -3.13% slice::bench::sort_large_descending 13,694 (5841 MB/s) 13,514 (5919 MB/s) -180 -1.31% slice::bench::sort_large_mostly_ascending 239,697 (333 MB/s) 203,542 (393 MB/s) -36,155 -15.08% slice::bench::sort_large_mostly_descending 270,102 (296 MB/s) 234,263 (341 MB/s) -35,839 -13.27% slice::bench::sort_large_random 513,406 (155 MB/s) 470,084 (170 MB/s) -43,322 -8.44% slice::bench::sort_large_random_expensive 23,650,321 (3 MB/s) 23,675,098 (3 MB/s) 24,777 0.10% slice::bench::sort_medium_ascending 143 (5594 MB/s) 132 (6060 MB/s) -11 -7.69% slice::bench::sort_medium_descending 197 (4060 MB/s) 188 (4255 MB/s) -9 -4.57% slice::bench::sort_medium_random 3,358 (238 MB/s) 3,271 (244 MB/s) -87 -2.59% slice::bench::sort_small_ascending 32 (2500 MB/s) 32 (2500 MB/s) 0 0.00% slice::bench::sort_small_big_ascending 97 (13195 MB/s) 97 (13195 MB/s) 0 0.00% slice::bench::sort_small_big_descending 247 (5182 MB/s) 249 (5140 MB/s) 2 0.81% slice::bench::sort_small_big_random 502 (2549 MB/s) 498 (2570 MB/s) -4 -0.80% slice::bench::sort_small_descending 55 (1454 MB/s) 61 (1311 MB/s) 6 10.91% slice::bench::sort_small_random 358 (223 MB/s) 356 (224 MB/s) -2 -0.56% ```
…oogaloo, r=petrochenkov continue to prefer hyphens in test files named after issue numbers a [followup](rust-lang#38473 (comment)) to rust-lang#38473 (The files in `auxillary/` directories have an excuse, as they get used as crates/modules, for which snake_case names make more sense.)
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @sfackler (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
@bors r+ p=50 |
|
📌 Commit be95d13 has been approved by |
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.
FileDesc::set_{nonblocking,cloexec}#39514, More snap cleanup #39519, [LLVM 4.0] Support a debug info API change for LLVM 4.0 #39528, ignore more gdb versions with buggy rust support #39530, Slightly optimize slice::sort #39538, continue to prefer hyphens in test files named after issue numbers #39556