Rollup of 9 pull requests #47984
Closed
Rollup of 9 pull requests #47984
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
Feb 3, 2018
•
kennytm
commented
- Successful merges: Update book #47753, Fix const evaluation ICE in rustdoc #47862, Do not ignore lifetime bounds in Copy impls #47877, decline to lint technically-unnecessary parens in function or method arguments inside of nested macros #47896, Use a range to identify SIGSEGV in stack guards #47912, Implement TrustedLen for Take<Repeat> and Take<RangeFrom> #47944, Stabilize feature(match_beginning_vert) #47947, ui tests: diff from old (expected) to new (actual) instead of backwards. #47978, Clarify shared file handler behavior of File::try_clone. #47958
- Failed merges:
Includes rust-lang/book#1088 and rust-lang/book@62210e3
In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the unused-parens lint was made to check function and method arguments, which it previously did not (seemingly due to oversight rather than willful design). However, in rust-lang#47775 and discussion thereon, user–developers of Geal/nom and graphql-rust/juniper reported that the lint was seemingly erroneously triggering on certain complex macros in those projects. While this doesn't seem like a bug in the lint in the particular strict sense that the expanded code would, in fact, contain unncecessary parentheses, it also doesn't seem like the sort of thing macro authors should have to think about: the spirit of the unused-parens lint is to prevent needless clutter in code, not to give macro authors extra heartache in the handling of token trees. We propose the expediency of declining to lint unused parentheses in function or method args inside of nested expansions: we believe that this should eliminate the petty, troublesome lint warnings reported in the issue, without forgoing the benefits of the lint in simpler macros. It seemed like too much duplicated code for the `Call` and `MethodCall` match arms to duplicate the nested-macro check in addition to each having their own `for` loop, so this occasioned a slight refactor so that the function and method cases could share code—hopefully the overall intent is at least no less clear to the gentle reader. This is concerning rust-lang#47775.
and improve printing of errors
Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range<usize>` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option<!>`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes rust-lang#47863.
…chton Update book This PR does two things: 1. update the book to include rust-lang/book#1088 2. update to mdbook 0.1 Both of these things are big changes, so I want to land them now, well before the next branch, so we can kick the tires. ------------------------------ Locally, I'm seeing some weirdness around the reference and this:  Putting this PR up so others can try and build and see if it reproduces for them.
…, r=eddyb Fix const evaluation ICE in rustdoc Fixes rust-lang#47860. r? @eddyb
… r=nikomatsakis Do not ignore lifetime bounds in Copy impls cc rust-lang#29149 r? @nikomatsakis
…ssary_unnecessary_parens, r=nikomatsakis decline to lint technically-unnecessary parens in function or method arguments inside of nested macros In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the unused-parens lint was made to check function and method arguments, which it previously did not (seemingly due to oversight rather than willful design). However, in rust-lang#47775 and discussion thereon, user–developers of Geal/nom and graphql-rust/juniper reported that the lint was seemingly erroneously triggering on certain complex macros in those projects. While this doesn't seem like a bug in the lint in the particular strict sense that the expanded code would, in fact, contain unncecessary parentheses, it also doesn't seem like the sort of thing macro authors should have to think about: the spirit of the unused-parens lint is to prevent needless clutter in code, not to give macro authors extra heartache in the handling of token trees. We propose the expediency of declining to lint unused parentheses in function or method args inside of nested expansions: we believe that this should eliminate the petty, troublesome lint warnings reported in the issue, without forgoing the benefits of the lint in simpler macros. It seemed like too much duplicated code for the `Call` and `MethodCall` match arms to duplicate the nested-macro check in addition to each having their own `for` loop, so this occasioned a slight refactor so that the function and method cases could share code—hopefully the overall intent is at least no less clear to the gentle reader. This is concerning rust-lang#47775.
…ichton Use a range to identify SIGSEGV in stack guards Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range<usize>` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option<!>`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes rust-lang#47863.
…n, r=bluss Implement TrustedLen for Take<Repeat> and Take<RangeFrom> This will allow optimization of simple `repeat(x).take(n).collect()` iterators, which are currently not vectorized and have capacity checks. This will only support a few aggregates on `Repeat` and `RangeFrom`, which might be enough for simple cases, but doesn't optimize more complex ones. Namely, Cycle, StepBy, Filter, FilterMap, Peekable, SkipWhile, Skip, FlatMap, Fuse and Inspect are not marked `TrustedLen` when the inner iterator is infinite. Previous discussion can be found in rust-lang#47082 r? @alexcrichton
…inning_vert, r=petrochenkov Stabilize feature(match_beginning_vert) With this feature stabilized, match expressions can optionally have a `|` at the beginning of each arm. Reference PR: rust-lang/reference#231 Closes rust-lang#44101
ui tests: diff from old (expected) to new (actual) instead of backwards. Previously `actual` was "old" and `expected` was "new" which resulted in `+` before `-`. AFAIK all diff tools put `-` before `+`, which made the previous behavior *very confusing*. r? @nikomatsakis
|
r? @KodrAus (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=8 |
|
📌 Commit b1bab59 has been approved by |
Clarify shared file handler behavior of File::try_clone. Fixes rust-lang#46578.
|
📌 Commit ec010ae has been approved by |
bors
added a commit
that referenced
this pull request
Feb 3, 2018
|
💔 Test failed - 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.