Rollup of 8 pull requests #47993
Closed
Rollup of 8 pull requests #47993
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 4, 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, Stabilize feature(match_beginning_vert) #47947, Clarify shared file handler behavior of File::try_clone. #47958, ui tests: diff from old (expected) to new (actual) instead of backwards. #47978
- Failed merges: Stabilize use_nested_groups #47948
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.
…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
Clarify shared file handler behavior of File::try_clone. Fixes rust-lang#46578.
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? @BurntSushi (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=8 |
|
📌 Commit cdb05b5 has been approved by |
kennytm
added
the
S-waiting-on-bors
|
⌛ Testing commit cdb05b5 with merge 643fb97a6d6d9c976667557ce61e23ef5ad568f0... |
|
💔 Test failed - status-appveyor |
|
🔒 Merge conflict |
|
☔ The latest upstream changes (presumably #47991) made this pull request unmergeable. Please resolve the merge conflicts. |
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.