Bump version, upgrade bootstrap

[alexcrichton]

This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.

[rust-highfive]

r? @nikomatsakis

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

[alexcrichton]

r? @brson

Also cc @nagisa, @est31 about the i128 staging changes. Would be good to have a second pair of eyes!

[nagisa]

Changes look good to me.

[est31]

LGTM to me as well. But we'll only know for sure once bors says its okay :) Little nit: impl LargeInt for u64 and impl LargeInt for i64 could be removed from compiler builtins, if I'm not mistaken.

[alexcrichton]

@est31 removed!

[brson]

@bors r+

[bors]

📌 Commit 64280d2 has been approved by brson

[alexcrichton]

@bors: p=1

(requested by @nagisa)

[bors]

⌛ Testing commit 64280d2 with merge 68ae9c1...

[bors]

💔 Test failed - status-travis

[alexcrichton]

@bors: r=brson

[bors]

📌 Commit 98f1d20 has been approved by brson

[bors]

⌛ Testing commit 98f1d20 with merge 3386812...

[bors]

💔 Test failed - status-appveyor

[alexcrichton]

@bors: retry

• cargo test failed to delete a file... here's to praying it's spurious!

[bors]

⌛ Testing commit 98f1d20 with merge 7803f96...

[bors]

💔 Test failed - status-travis

[alexcrichton]

@bors: retry * sccache wedged #39003

…

On Fri, Feb 3, 2017 at 11:09 AM, bors ***@***.***> wrote: 💔 Test failed - status-travis <https://travis-ci.org/rust-lang/rust/builds/198104074> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#39463 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD95IfFATYNVNeSG3-Xgza0YTMvSxinks5rY3tbgaJpZM4L1dr9> .

[bors]

⌛ Testing commit 98f1d20 with merge 1d20da1...

[bors]

💔 Test failed - status-appveyor

[est31]

Hmm it seems like a spurious bug with Cargo. If code that created this error gets executed with itself in parallel, then it can in theory both times assume that dst exists, leading to the remove being attempted. One instance will then succeed, while the other instance will fail as the file was already removed. According to this playground example, attempting to non existent files leads in the NotFound error kind. Maybe ignore the error if that's the case?

Either way, it looks like the error is spurious, so a retry should be attempted.

[alexcrichton]

Thanks for the investigation @est31, I'll keep digging and see if I can't come up with a solution.

For now I've backed out the update to Cargo, filed #39504 to track the future update, and otherwise let's land the removal of the i128 staging

@bors: r+

[bors]

📌 Commit 626e754 has been approved by alexcrichton

[bors]

⌛ Testing commit 626e754 with merge 0648517...

[bors]

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