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 22 pull requests #52882

Closed
wants to merge 63 commits into from

Conversation

Mark-Simulacrum
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

Xandkeeper and others added 30 commits April 26, 2018 18:14
Allow target specs to disable that attribute.
Refer instead to thanks page.
…r=QuietMisdreavus

Delete unused code in rustdoc

Also hid the unused crate exports of rustdoc. This is technically a breaking change but we don't even ship librustdoc in the sysroot so I don't expect breakage.
Update clippy to latest master

r? @oli-obk

There is a regression in the version in current nightly that falsely lints `println!` and `writeln!` that use named arguments, thinking all rhs values for the argument expressions are literals even when they are not. This update includes the fix for that.
rustc: Disallow machine applicability in foreign macros

Recent changes to lints disallowed lints from being emitted against code located
in foreign macros, except for future-incompatible lints. For a future
incompatible lint, however, the automatic suggestions may not be applicable!

This commit updates this code path to force all applicability suggestions made
to foreign macros to never be `MachineApplicable`. This should avoid rustfix
actually attempting fixing these suggestions, causing non-compiling code to be
produced.

Closes rust-lang/cargo#5799
Clarify thread::park semantics

It took me quite some time to realize that the example is not actually racy, so let's clarify it? :-)
…aelwoerister

pretty print for std::collections::vecdeque

I want pretty print function for VecDeque like Vec.

```rust
use std::collections::VecDeque;

fn main() {
    let mut d: VecDeque<i32> = VecDeque::new();
    d.push_back(4);
    d.push_back(4);
    d.push_back(6);
    let mut v: Vec<i32> = Vec::new();
    v.push(4);
    v.push(4);
    v.push(6);
}
```

```
(gdb) p v
$1 = Vec<i32>(len: 3, cap: 4) = {4, 4, 6}
(gdb) p d
$2 = VecDeque<i32>(len: 3, cap: 8) = {4, 4, 6}
```

Thanks.
…, r=cramertj

Fix From<LocalWaker>

This is a follow-up to rust-lang#52640

Fixes `From<LocalWaker>` which is affected by the same accidental drop bug (unless I'm totally mistaken)

r? @cramertj
…r=rkruppe

Fix -Wpessimizing-move warnings in rustllvm/PassWrapper

These are producing warnings when building rustc (`warning: moving a local object in a return statement prevents copy elision [-Wpessimizing-move]`).
Make sure rust-lang#47772 does not regress

Mostly to make my life in rust-lang#52206 harder.^^

Or should I just add that test there?
…lexcrichton

remove references to AUTHORS.txt file

Rust does not ship an AUTHORS.txt file anymore.
…ark-Simulacrum

Add timeout to use of `curl` in bootstrap.py.

Recently we've seen a lot of "30 minutes no output" spurious errors while downloading the bootstrap compiler. This added several timeout options so if the "30 minutes no output" errors were caused by connection or transfer issue, we could fail quicker for curl to retry.
Revert "Stabilize to_bytes and from_bytes for integers."

This reverts commit c8f9b84 / PR rust-lang#51835, and reopens the tracking issue rust-lang#49792.

These methods were stabilized in Rust 1.29, which is still in Nightly as of this writing. So my understanding is that it is still time to change our minds. Given the ongoing discussion in rust-lang#51919 about possibly renaming these APIs and since 1.29 goes to beta soon, I’d like to revert this stabilization for now until a decision is made in that PR. It’s possible that a decision will be made in time for 1.29, but there is no urgency. At most I expect this functionality to make it into 1.30.
Implement Unpin for FutureObj and LocalFutureObj

cc @MajorBreakfast

r? @aturon
Fix wrong issue number in the test name

I made a mistake in previous PR rust-lang#52620, second issue number was wrong, changing from rust-lang#52133 to rust-lang#52113

r? @kennytm
@Mark-Simulacrum
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Jul 30, 2018

📌 Commit baf6b76 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 Jul 30, 2018
@bors
Copy link
Contributor

bors commented Jul 31, 2018

⌛ Testing commit baf6b76 with merge c8436ae882ce41f4134a94ae38db462dc07a8461...

@bors
Copy link
Contributor

bors commented Jul 31, 2018

💔 Test failed - status-appveyor

@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 Jul 31, 2018
@RalfJung
Copy link
Member

Seems like that's my PR (#52825):

C:\projects\rust\build\x86_64-pc-windows-gnu\test\codegen\slice-position-bounds-check\slice-position-bounds-check.ll:13:233: error: CHECK-NOT: string occurred!
define zeroext i1 @position_no_bounds_check([0 x i32]* noalias nonnull %y.0, i64 %y.1, i32* noalias nocapture readonly dereferenceable(4) %x, i32* noalias nocapture readonly dereferenceable(4) %z) unnamed_addr #0 personality i32 (%"panic_unwind::windows::EXCEPTION_RECORD"*, i8*, %"panic_unwind::windows::CONTEXT"*, %"panic_unwind::windows::DISPATCHER_CONTEXT"*)* @rust_eh_personality {
                                                                                                                                                                                                                                        ^
C:\projects\rust\src/test\codegen\slice-position-bounds-check.rs:28:16: note: CHECK-NOT: pattern specified here
 // CHECK-NOT: panic
               ^

@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.