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 8 pull requests #48947

Closed
wants to merge 19 commits into from

Conversation

Phlosioneer and others added 19 commits March 6, 2018 23:17
Wrapping<T> now implements:

count_ones, count_zeros, leading_zeros,
trailing_zeros, rotate_left, rotate_right, swap_bytes, from_be,
from_le, to_be, to_le, and pow

where T is:

u8, u16, u32, u64, usize, i8, i16, i32, i64, or isize.

Docs were written for all these methods, as well as examples. The
examples mirror the ones on u8, u16, etc... for consistency.

Closes rust-lang#32463
(Meanwhile, a couple of parse-fail tests are moved to UI tests so that
the reader can see the new output, and an existing UI test is given a
more evocative name.)
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".

Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.

This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
Pulls in a redesigned `std::simd` module as well as a replacement for the
`is_target_feature_detected!` macro
When executing run-make tests we run a risk of leaking the `MAKEFLAGS`
environment variable if `./x.py` itself was called from `make` (aka `make check
-j3` as the OSX bots do). We may then leak accidentally fds into the child
process and trick it into thinking it's got a jobserver!

Hopefully addresses [this] spurious failure

[this]: rust-lang#48295 (comment)
…wrapping, r=dtolnay

Implement Integer methods for Wrapping

Wrapping<T> now implements:

count_ones, count_zeros, leading_zeros,
trailing_zeros, rotate_left, rotate_right, swap_bytes, from_be,
from_le, to_be, to_le, and pow

where T is:

u8, u16, u32, u64, usize, i8, i16, i32, i64, or isize.

Docs were written for all these methods, as well as examples. The
examples mirror the ones on u8, u16, etc... for consistency.

Closes rust-lang#32463
tidy: Add a check for stray `.stderr` and `.stdout` files in UI test directories
Update stdsimd module

Pulls in a redesigned `std::simd` module as well as a replacement for the
`is_target_feature_detected!` macro
…lf, r=petrochenkov

refactor the `BorrowckErrors` trait to take `fn(self)`

Fixes rust-lang#48783
…y, r=estebank

in which some labels and notes are upgraded to structured suggestions

(Meanwhile, a couple of parse-fail tests are moved to UI tests so that
the reader can see the new output, and an existing UI test is given a
more evocative name.)

r? @estebank
…etrochenkov

Fix hygene issue when deriving Debug

The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".

Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.

This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].

I also checked the implementations of the other built-in derives to
ensure they didn't declare any variables.
…ennytm

test: Forcibly remove MAKEFLAGS in compiletest

When executing run-make tests we run a risk of leaking the `MAKEFLAGS`
environment variable if `./x.py` itself was called from `make` (aka `make check
-j3` as the OSX bots do). We may then leak accidentally fds into the child
process and trick it into thinking it's got a jobserver!

Hopefully addresses [this] spurious failure

[this]: rust-lang#48295 (comment)
@rust-highfive
Copy link
Collaborator

r? @BurntSushi

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

@Mark-Simulacrum
Copy link
Member Author

@bors r+ p=5

@bors
Copy link
Contributor

bors commented Mar 12, 2018

📌 Commit 911f6f1 has been approved by Mark-Simulacrum

@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 12, 2018
@bors
Copy link
Contributor

bors commented Mar 12, 2018

⌛ Testing commit 911f6f1 with merge 0de9b83bb87ecd9e16a30c8da443d19aa7f93871...

@bors
Copy link
Contributor

bors commented Mar 12, 2018

💔 Test failed - status-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 12, 2018
@kennytm
Copy link
Member

kennytm commented Mar 12, 2018

Same error as #48921 (comment). One of the rolled up PR is causing the error but we don't know which. The common PRs between the two rollups are:

@kennytm kennytm closed this Mar 12, 2018
@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.