Upgrade rustup used on AppVeyor #3996
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
I've totally forgotten the error, let's find out what it is again! @bors: r+ |
|
📌 Commit 3e1ed70 has been approved by |
|
⌛ Testing commit 3e1ed70 with merge 655a073... |
|
💔 Test failed - status-appveyor |
|
@bors: r+ |
|
📌 Commit 4ff9b5e has been approved by |
|
💔 Test failed - status-appveyor |
|
@bors: r+ |
|
📌 Commit d869907 has been approved by |
|
⌛ Testing commit d869907 with merge eae061f... |
|
💔 Test failed - status-travis |
|
@bors: retry
…On Fri, May 5, 2017 at 11:06 AM, bors ***@***.***> wrote:
💔 Test failed - status-travis
<https://travis-ci.org/rust-lang/cargo/builds/229144620?utm_source=github_status&utm_medium=notification>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3996 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD95BkT-BcOSyqk54s1qZ38WhfsNpkZks5r20jwgaJpZM4NRQ33>
.
|
|
☀️ Test successful - status-appveyor, status-travis |
bors
added a commit
that referenced
this pull request
May 9, 2017
fix `cargo test` of dylib projects for end user runs too Fixes running `cargo test` and `cargo test --target <target>` for dylib projects. Moves the logic just landed in #3996 into cargo itself, so cargo sets the dylib path for anyone running `cargo test` or `cargo run`. Current master sets the dylib path only for `cargo test` on cargo itself. This PR pins to rustup 1.2.0 for the purposes of testing. If rust-lang/rustup#1093 ends up working out, then this PR would only be important for non-rustup users and people doing cross testing, `cargo test --target <target>`. Arguably https://github.com/mcgoo/cargo/blob/ed273851f8bc76f726eda4a2e2a7bb470c3718bc/src/cargo/ops/cargo_rustc/context.rs#L249-L253 should point to lib/rustlib/\<host triple\>/lib instead of sysroot/lib, because I think if the libs are different, you will never be able to compile a working plugin anyway, and for the host=target case you get the lib/rustlib/\<host triple\>/lib anyhow. Is there ever a case where the lib/rustlib/\<host triple\>/lib and sysroot/lib versions of the libs would be expected to differ? This is not a huge deal for me one way or the other - it doesn't impact my workflow at all. I nearly dropped it when I saw @alexcrichton had made it all work in 3996, but I think it's worth doing because it removes a surprise. It certainly would have saved me a couple of days of confusion. Either way, thanks for looking it over.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.