Skip to content
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 17 pull requests #59466

Closed
wants to merge 63 commits into from
Closed

Rollup of 17 pull requests #59466

wants to merge 63 commits into from

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Mar 27, 2019

Successful merges:

Failed merges:

r? @ghost

hellow554 and others added 30 commits February 25, 2019 07:09
uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
Centril added 16 commits March 27, 2019 17:45
syntax: Remove warning for unnecessary path disambiguators

`rustfmt` is now stable and it removes unnecessary turbofishes, so removing the warning as discussed in rust-lang#43540 (where it was introduced).
One hardcoded warning less.

Closes rust-lang#58055

r? @nikomatsakis
…rochenkov

librustc_driver => 2018

Transitions `librustc_driver` to Rust 2018; cc rust-lang#58099

r? @Centril
Add FromStr impl for NonZero types

This is a WIP implementation because I do have some questions regarding the solution.

Somebody should ping the lang team on this I guess.
Please see the annotations on the code for more details.

Closes rust-lang#58604
…petrochenkov

librustc_interface => 2018

r? @oli-obk

This will likely produce an ICE for some reason... so super-WIP.
…avus

Add suggestion to use `&*var` when `&str: From<String>` is expected

Fix rust-lang#53879.
…=joshtriplett

Make ASCII case conversions more than 4× faster

Reformatted output of `./x.py bench src/libcore --test-args ascii` below. The `libcore` benchmark calls `[u8]::make_ascii_lowercase`. `lookup` has code (effectively) identical to that before this PR, and ~~`branchless`~~ `mask_shifted_bool_match_range` after this PR.

~~See [code comments](rust-lang@ce933f7#diff-01076f91a26400b2db49663d787c2576R3796) in `u8::to_ascii_uppercase` in `src/libcore/num/mod.rs` for an explanation of the branchless algorithm.~~

**Update:** the algorithm was simplified while keeping the performance. See `branchless` v.s. `mask_shifted_bool_match_range` benchmarks.

Credits to @raphlinus for the idea in https://twitter.com/raphlinus/status/1107654782544736261, which extends this algorithm to “fake SIMD” on `u32` to convert four bytes at a time. The `fake_simd_u32` benchmarks implements this with [`let (before, aligned, after) = bytes.align_to_mut::<u32>()`](https://doc.rust-lang.org/std/primitive.slice.html#method.align_to_mut). Note however that this is buggy when addition carries/overflows into the next byte (which does not happen if the input is known to be ASCII).

This could be fixed (to optimize `[u8]::make_ascii_lowercase` and `[u8]::make_ascii_uppercase` in `src/libcore/slice/mod.rs`) either with some more bitwise trickery that I didn’t quite figure out, or by using “real” SIMD intrinsics for byte-wise addition. I did not pursue this however because the current (incorrect) fake SIMD algorithm is only marginally faster than the one-byte-at-a-time branchless algorithm. This is because LLVM auto-vectorizes the latter, as can be seen on https://rust.godbolt.org/z/anKtbR.

Benchmark results on Linux x64 with Intel i7-7700K: (updated from rust-lang#59283 (comment))

```rust
6830 bytes string:

alloc_only                          ... bench:    112 ns/iter (+/- 0) = 62410 MB/s
black_box_read_each_byte            ... bench:  1,733 ns/iter (+/- 8) = 4033 MB/s
lookup_table                        ... bench:  1,766 ns/iter (+/- 11) = 3958 MB/s
branch_and_subtract                 ... bench:    417 ns/iter (+/- 1) = 16762 MB/s
branch_and_mask                     ... bench:    401 ns/iter (+/- 1) = 17431 MB/s
branchless                          ... bench:    365 ns/iter (+/- 0) = 19150 MB/s
libcore                             ... bench:    367 ns/iter (+/- 1) = 19046 MB/s
fake_simd_u32                       ... bench:    361 ns/iter (+/- 2) = 19362 MB/s
fake_simd_u64                       ... bench:    361 ns/iter (+/- 1) = 19362 MB/s
mask_mult_bool_branchy_lookup_table ... bench:  6,309 ns/iter (+/- 19) = 1107 MB/s
mask_mult_bool_lookup_table         ... bench:  4,183 ns/iter (+/- 29) = 1671 MB/s
mask_mult_bool_match_range          ... bench:    339 ns/iter (+/- 0) = 20619 MB/s
mask_shifted_bool_match_range       ... bench:    339 ns/iter (+/- 1) = 20619 MB/s

32 bytes string:

alloc_only                          ... bench:     15 ns/iter (+/- 0) = 2133 MB/s
black_box_read_each_byte            ... bench:     29 ns/iter (+/- 0) = 1103 MB/s
lookup_table                        ... bench:     24 ns/iter (+/- 4) = 1333 MB/s
branch_and_subtract                 ... bench:     16 ns/iter (+/- 0) = 2000 MB/s
branch_and_mask                     ... bench:     16 ns/iter (+/- 0) = 2000 MB/s
branchless                          ... bench:     16 ns/iter (+/- 0) = 2000 MB/s
libcore                             ... bench:     15 ns/iter (+/- 0) = 2133 MB/s
fake_simd_u32                       ... bench:     17 ns/iter (+/- 0) = 1882 MB/s
fake_simd_u64                       ... bench:     16 ns/iter (+/- 0) = 2000 MB/s
mask_mult_bool_branchy_lookup_table ... bench:     42 ns/iter (+/- 0) = 761 MB/s
mask_mult_bool_lookup_table         ... bench:     35 ns/iter (+/- 0) = 914 MB/s
mask_mult_bool_match_range          ... bench:     16 ns/iter (+/- 0) = 2000 MB/s
mask_shifted_bool_match_range       ... bench:     16 ns/iter (+/- 0) = 2000 MB/s

7 bytes string:

alloc_only                          ... bench:     14 ns/iter (+/- 0) = 500 MB/s
black_box_read_each_byte            ... bench:     22 ns/iter (+/- 0) = 318 MB/s
lookup_table                        ... bench:     16 ns/iter (+/- 0) = 437 MB/s
branch_and_subtract                 ... bench:     16 ns/iter (+/- 0) = 437 MB/s
branch_and_mask                     ... bench:     16 ns/iter (+/- 0) = 437 MB/s
branchless                          ... bench:     19 ns/iter (+/- 0) = 368 MB/s
libcore                             ... bench:     20 ns/iter (+/- 0) = 350 MB/s
fake_simd_u32                       ... bench:     18 ns/iter (+/- 0) = 388 MB/s
fake_simd_u64                       ... bench:     21 ns/iter (+/- 0) = 333 MB/s
mask_mult_bool_branchy_lookup_table ... bench:     20 ns/iter (+/- 0) = 350 MB/s
mask_mult_bool_lookup_table         ... bench:     19 ns/iter (+/- 0) = 368 MB/s
mask_mult_bool_match_range          ... bench:     19 ns/iter (+/- 0) = 368 MB/s
mask_shifted_bool_match_range       ... bench:     19 ns/iter (+/- 0) = 368 MB/s
```
adjust MaybeUninit API to discussions

uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
add rustfix-able suggestions to trim_{left,right} deprecations

Fixes rust-lang#53802 (technically already fixed by rust-lang#58002, but that issue is about these methods).
…tests, r=shepmaster

Refactor tuple comparison tests
…ochenkov

Reject integer suffix when tuple indexing

Fix rust-lang#59418.

r? @varkor
…erpretcx, r=oli-obk

Renames `EvalContext` to `InterpretCx`

This PR renames `EvalContext` to `InterpretCx` in `src/librustc_mir`.
This PR is related to rust-lang#54395 .
…iagnostic, r=oli-obk

Generalize diagnostic for `x = y` where `bool` is the expected type

Extracted out of rust-lang#59288.

Currently we special case a diagnostic for `if x = y { ...` since the expected type is `bool` in this case and we instead suggest `if x == y`. This PR generalizes this such that given an expression of form `x = y` (`ExprKind::Assign(..)`) where the expected type is `bool`, we emit a suggestion `x == y`.

r? @oli-obk

Let's do a perf run to make sure this was not the source of regressions in rust-lang#59288.
fix: Make incremental artifact deletion more robust

Should fix the intermittent errors reported in rust-lang#57958

cc rust-lang#48614
Add `Default` to `std::alloc::System`

`System` is a unit struct, thus, it can be constructed without any additional information. Therefore `Default` is a noop. However, in generic code, a `T: Default` may happen as in

```rust
#[derive(Default)]
struct Foo<A> {
    allocator: A
}
```

Does this need a feature gate?
Should I also add `PartialEq/Eq/PartialOrd/Ord/Hash`?
Add some tests

close rust-lang#52977

It seems that there are no tests for this issue, so I opened this PR.
off-topic: I noticed [this test](https://github.com/rust-lang/rust/blob/master/src/test/ui/existential_types/nested_existential_types.rs)'s indents are bad, could I include commit to fix this, or should I separate?

r? @oli-obk
…Amanieu

Include id in Thread's Debug implementation

Since Rust 1.19.0, `id` is a stable method, so there is no reason to not include it in Debug implementation.
@Centril
Copy link
Contributor Author

Centril commented Mar 27, 2019

@bors r+ p=17

@bors
Copy link
Contributor

bors commented Mar 27, 2019

📌 Commit 3f372a1 has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 27, 2019
@bors
Copy link
Contributor

bors commented Mar 27, 2019

⌛ Testing commit 3f372a1 with merge 3f1b37d4dc16ffa506c31fe99e48084b0090c376...

@bors
Copy link
Contributor

bors commented Mar 27, 2019

💔 Test failed - checks-travis

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 27, 2019
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-debug of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:47:10] note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
[00:47:10] 
[00:47:10] note: rustc 1.35.0-dev running on x86_64-unknown-linux-gnu
[00:47:10] 
[00:47:10] note: compiler flags: -Z external-macro-backtrace -Z force-unstable-if-unmarked -C opt-level=2 -C prefer-dynamic -C linker=clang -C debug-assertions=y -C codegen-units=1 -C link-args=-Wl,-rpath,$ORIGIN/../lib --crate-type lib
[00:47:10] note: some of the compiler flags provided by cargo are hidden
[00:47:10] 
[00:47:10] [RUSTC-TIMING] core test:false 35.483
[00:47:10] error: Could not compile `core`.
---
travis_time:end:01a31cdf:start=1553723338260123622,finish=1553723338268262699,duration=8139077
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:10c3df04
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:02767ce0
travis_time:start:02767ce0
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:1108ba26
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@Centril Centril closed this Mar 27, 2019
@Centril Centril deleted the rollup branch March 27, 2019 21:51
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.