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 10 pull requests #47998

Merged
merged 21 commits into from Feb 5, 2018
Merged

Rollup of 10 pull requests #47998

merged 21 commits into from Feb 5, 2018

Conversation

spastorino and others added 18 commits January 30, 2018 14:00
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.
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.
Add rustc_const_unstable attribute for `any::TypeId::of`

Add test for `const fn TypeId::of`
…, 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
@rust-highfive
Copy link
Collaborator

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

@kennytm
Copy link
Member Author

kennytm commented Feb 4, 2018

@bors r+ p=7

@bors
Copy link
Contributor

bors commented Feb 4, 2018

📌 Commit 393cd89 has been approved by kennytm

@kennytm kennytm added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 4, 2018
Run the `run-make` tests last, so more tests run on Windows when `make` is unavailable
@kennytm kennytm changed the title Rollup of 7 pull requests Rollup of 9 pull requests Feb 4, 2018
@kennytm
Copy link
Member Author

kennytm commented Feb 4, 2018

@bors r+

Added #47996, #47999, #47892

@bors
Copy link
Contributor

bors commented Feb 4, 2018

📌 Commit 66d6c85 has been approved by kennytm

Turn `type_id` into a constant intrinsic

rust-lang#27745

The method `get_type_id` in `Any` is intended to support reflection. It's currently unstable in favor of using an associated constant instead. This PR makes the `type_id` intrinsic a constant intrinsic, the same as `size_of` and `align_of`, allowing `TypeId::of` to be a `const fn`, which will allow using an associated constant in `Any`.
@bors
Copy link
Contributor

bors commented Feb 4, 2018

📌 Commit e17ebdf has been approved by kennytm

@kennytm kennytm changed the title Rollup of 9 pull requests Rollup of 10 pull requests Feb 4, 2018
@bors
Copy link
Contributor

bors commented Feb 4, 2018

⌛ Testing commit e17ebdf with merge 7dd3864...

bors added a commit that referenced this pull request Feb 4, 2018
Rollup of 10 pull requests

- Successful merges: #47862, #47877, #47896, #47912, #47947, #47958, #47978, #47996, #47999, #47892
- Failed merges:
@bors
Copy link
Contributor

bors commented Feb 4, 2018

💔 Test failed - status-appveyor

@kennytm
Copy link
Member Author

kennytm commented Feb 4, 2018

@bors retry #46903

@bors
Copy link
Contributor

bors commented Feb 4, 2018

⌛ Testing commit e17ebdf with merge e7e982a...

bors added a commit that referenced this pull request Feb 4, 2018
Rollup of 10 pull requests

- Successful merges: #47862, #47877, #47896, #47912, #47947, #47958, #47978, #47996, #47999, #47892
- Failed merges:
@bors
Copy link
Contributor

bors commented Feb 5, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: kennytm
Pushing e7e982a to master...

@bors bors merged commit e17ebdf into rust-lang:master Feb 5, 2018
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet