Update to latest nightly #963
Conversation
|
@bors r+ |
|
📌 Commit 20b10cc has been approved by |
|
💔 Test failed - checks-travis |
|
osx failure due to rust-lang/rust-clippy#4576 (comment) |
|
@RalfJung should we turn off osx for now or wait until it's fixed? |
|
@bors r+ seems it's fixed |
|
📌 Commit 9fdb347 has been approved by |
|
💔 Test failed - checks-travis |
|
So the issue is that cargo stable is broken on macOS? Because I think that is the only cargo we are using here. Is this related to the 1.38 release? |
|
Looks fixed now... strange. @bors r+ |
|
📌 Commit 9f6287e has been approved by |
| @@ -59,5 +59,5 @@ cargo_miri = ["cargo_metadata", "directories", "rustc_version"] | |||
| rustc_tests = [] | |||
|
|
|||
| [dev-dependencies] | |||
| compiletest_rs = { version = "0.3.22", features = ["tmp", "stable"] } | |||
| compiletest_rs = { version = "0.3.23", features = ["tmp"] } | |||
There was a problem hiding this comment.
Did clippy make the same feature switch? If not, this will likely trigger the duplicate complication check when we update Miri in rustc.
There was a problem hiding this comment.
Yeah, half year ago: rust-lang/rust-clippy@a8ce9d6
😀
There was a problem hiding this comment.
lol.^^
That makes me wonder why we did not trigger the aforementioned check all along. Oh well.
There was a problem hiding this comment.
It's under dev-dependencies, it doesn't end up in the binary.
There was a problem hiding this comment.
But the purpose of the check is ti reduce build times. Binary or not shouldn't matter.
|
@RalfJung previously the same thing happened. It worked as PR build but failed as merge build. |
|
|
|
Oh dang. Looks like the build cache for the |
|
@bors r+ |
|
📌 Commit 2701599 has been approved by |
|
💔 Test failed - checks-travis |
|
@bors r+ |
|
📌 Commit 76c76b4 has been approved by |
|
💔 Test failed - checks-travis |
|
@bors r+ |
|
📌 Commit c424e06 has been approved by |
|
☀️ Test successful - checks-travis, status-appveyor |
No description provided.