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 9 pull requests #61789

Merged
merged 20 commits into from
Jun 13, 2019
Merged

Rollup of 9 pull requests #61789

merged 20 commits into from
Jun 13, 2019

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Jun 12, 2019

Successful merges:

Failed merges:

r? @ghost

kennytm and others added 20 commits May 31, 2019 20:02
This ensures we won't accidentally read *src or *dest even when count = 0.
Co-Authored-By: Jack O'Connor <oconnor663@gmail.com>
Make sure we look for save analysis in the right place. Fixes rust-lang#61703.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
The condition I suggested in rust-lang#61632 was not correct and it errors out
while evaluating. This fixes the condition.

Example of a failure:
https://dev.azure.com/rust-lang/rust/_build/results?buildId=543
Hygienize macros in the standard library

Same as rust-lang#55597, but for all macros in the standard library.
Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site.
Technically this is a breaking change, so crater run would probably be useful.

---

One exception that is not hygienized is calls to `panic!(...)`.
Macros defined in libcore do not want to call `core::panic`.
What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings.
EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done).

Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code.

The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic.
Then standard library macros could delegate to this built-in macro.
The macro could be named `panic` too, that would fix rust-lang#61567.
(This PR doesn't do that.)

---
cc rust-lang#56389
cc rust-lang#61567
Fixes rust-lang#61699
r? @alexcrichton
Include frame pointer for bare metal RISC-V targets

This changes the default setting to enable the use of the frame pointer register when targeting RISC-V. On that architecture there is a dedicated frame pointer register which LLVM would otherwise never use so there is no increase in register pressure. Further, since these are bare metal targets, getting backtraces without the frame pointer is considerably more difficult (you can't just ask the OS to load the ELF executable and parse DWARF symbols). It is true that this setting can also be changed with the `-C force-frame-pointers` flag but that won't impact the compilation of the standard library, meaning that backtraces from, say, a panic handler would be useless.
Fix x.py install

Make sure we look for save analysis in the right place. Fixes rust-lang#61703.

r? @Mark-Simulacrum
cc @petrhosek @cramertj
Add an alias for x86_64-sun-solaris target tuple

Closes rust-lang#40531

r? @varkor
…rk-Simulacrum

rustbuild: fix libtest_stamp

Looks like an obvious copy/paste typo
…=alexcrichton

ci: fix ci stats upload condition

The condition I suggested in rust-lang#61632 was not correct and it errors out while evaluating. This fixes the condition. [Example of a failure](https://dev.azure.com/rust-lang/rust/_build/results?buildId=543).

r? @alexcrichton
…r=Centril

Fix typos in error_codes

`observedin` should be `observed in`.
@Centril
Copy link
Contributor Author

Centril commented Jun 12, 2019

@bors r+ p=9 rollup=never

@bors
Copy link
Contributor

bors commented Jun 12, 2019

📌 Commit af281d2 has been approved by Centril

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

bors commented Jun 13, 2019

⌛ Testing commit af281d2 with merge d8f50ab...

bors added a commit that referenced this pull request Jun 13, 2019
Rollup of 9 pull requests

Successful merges:

 - #60376 (Stabilize Option::xor)
 - #61398 (Stabilize copy_within)
 - #61629 (Hygienize macros in the standard library)
 - #61675 (Include frame pointer for bare metal RISC-V targets)
 - #61750 (Fix x.py install)
 - #61761 (Add an alias for x86_64-sun-solaris target tuple)
 - #61762 (rustbuild: fix libtest_stamp)
 - #61763 (ci: fix ci stats upload condition)
 - #61776 (Fix typos in error_codes)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jun 13, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: Centril
Pushing d8f50ab to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 13, 2019
@bors bors merged commit af281d2 into rust-lang:master Jun 13, 2019
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #61789!

Tested on commit d8f50ab.
Direct link to PR: #61789

💔 rls on linux: test-pass → test-fail (cc @Xanewok, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jun 13, 2019
Tested on commit rust-lang/rust@d8f50ab.
Direct link to PR: <rust-lang/rust#61789>

💔 rls on linux: test-pass → test-fail (cc @Xanewok, @rust-lang/infra).
@Centril Centril deleted the rollup-hhyvopq branch June 13, 2019 04:21
@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
merged-by-bors This PR was explicitly merged by bors. 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