Skip to content

Rollup of 8 pull requests #48947

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
Contributor

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
Collaborator

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
Collaborator

bors commented Mar 12, 2018

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

@bors
Copy link
Collaborator

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
# for free to join this conversation on GitHub. Already have an account? # 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.