Rollup of 7 pull requests #28913
Merged
Rollup of 7 pull requests #28913
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
This is to address issue rust-lang#28803
In rust-lang#28864, @Aarzee submitted some whitespace fixes. I r+'d it. But @retp998 noticed[1] that this file is explicitly a test of this kind of whitespace, and so I shouldn't have changed it. This restores the old line endings. 1: rust-lang#28864 (comment)
Add musl link
Currently the explain command requires full erorr codes, complete with the leading zeros and the E at the beginning. This commit changes that, if you don't supply a full erorr code then the error number is padded out to the required size and the E is added to the beginning. This means that where previously you would need to write E0001, you can now write 0001, 001, 01 or jsut 1 to refer to the same error.
Later in text we mention 'step four' and 'step three'. This fix releases user from counting.
Rest is blocked by https://github.com/nrc/rustfmt/issues/413
This is to address issue rust-lang#28803 by improving some of the references to closures, to explain what they are more clearly, while hopefully still being concise. r? @steveklabnik
In rust-lang#28864, @Aarzee submitted some whitespace fixes. I r+'d it. But @retp998 noticed[1] that this file is explicitly a test of this kind of whitespace, and so I shouldn't have changed it. This restores the old line endings. 1: rust-lang#28864 (comment)
…ichton The diff can hopefully speak for itself. Regardless: this chapter of the book contained a sentence where "the" was mistakenly repeated twice. In this same section, there was a comma separating two sentences where a period should have been. This PR fixes both issues.
<!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/28896) <!-- Reviewable:end -->
…chton It's not very common to store `Wrapping` values, but I kept wrapping and unwrapping a hash value when I taking it out of a struct to do operations on it. I couldn't store the hash as `Wrapping<u64>` because I wanted to be able to `#[derive(Default)]` for the struct. At any rate, it feels to me that `Wrapping<T>` should implement pretty much everything `T` does. I left out `#[derive(Hash)]` since I'd be hard pressed to find a use case and wanted to avoid the extra generated code, but maybe I should add that too?
This new version takes inspiration from the C implementation of the benchmark, but instead of explicitly using SIMD operations which can't be done on stable, it instead arranges everything the same way and leaves the actual vectorization up to LLVM. In addition to the ~20% speed gains (see below), this PR also adds some general niceties which showcase the language a little bit: a `Vec3` type to cut down on `(x, y, z)` repetition, using `while let` instead of `loop-if-break`, iterator adapters instead of for loops etc. Here are the times in seconds of 10 runs each on my workstation: ``` before: 6.254, 6.260, 6.263, 6.264, 6.265, 6.267, 6.334, 6.341, 6.441, 6.509 before-min: 6.254 before-median: 6.266 before-max: 6.509 after: 4.823, 4.824, 4.826, 4.827, 4.837, 4.839, 4.881, 4.959, 4.990, 5.377 after-min: 4.823 after-median: 4.838 after-max: 5.377 gcc: 4.674, 4.676, 4.680, 4.682, 4.695, 4.696, 4.701, 4.708, 4.794, 5.297 gcc-min: 4.674 gcc-median: 4.696 gcc-max: 5.297 ``` On my i7 laptop the speed up is less impressive, from ~5.4s to ~4.7s, but still significant. On my Vultr VPS the numbers look closer to the workstation results. Surprisingly my laptop beats both office workstation and VPS...
- Successful merges: rust-lang#28836, rust-lang#28856, rust-lang#28874, rust-lang#28876, rust-lang#28878, rust-lang#28880, rust-lang#28882, rust-lang#28885, rust-lang#28889, rust-lang#28896 - Failed merges:
Currently the explain command line flag requires full error codes, complete with the leading zeros and the E at the beginning. This commit changes that, if you don't supply a full error code then the error number is padded out to the required size and the E is added to the beginning. This means that where previously you would need to write E0001, you can now write 0001, 001, 01 or just 1 to refer to the same error.
|
r? @Manishearth (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors: r+ p=1 |
|
📌 Commit 1625c13 has been approved by |
bors
added a commit
that referenced
this pull request
Oct 8, 2015
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.
--explainHandle Partial Error Codes #28872, Comment on shadowing with patterns #28893, trpl: mention deriving in traits section #28904, reference: fix typos #28905, Fix typo in E0101 #28908, Format code-like text in Iterator::cloned doc-comment #28910