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

Recursive tool invocations should invoke the proxy, not the tool dire… #812

Merged
merged 1 commit into from Nov 23, 2016

Conversation

Projects
None yet
6 participants
@brson
Copy link
Contributor

brson commented Nov 15, 2016

…ctly

The way the proxy was setting up the PATH variable contained two bugs:
first, that it allowed the toolchain path to precede the value of CARGO_HOME/bin;
but second that it didn't add CARGO_HOME/bin to the path at all. The result
was that when e.g. cargo execs rustc, it was directly execing the toolchain
rustc.

Now it execs the proxy, assuming that CARGO_HOME/bin is set up correctly,
and guaranteeing not to run the toolchain tool directly.

Fixes #809

r? @Diggsey cc @japaric @michaelwoerister

@michaelwoerister

This comment has been minimized.

Copy link

michaelwoerister commented Nov 15, 2016

Nice! :D

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 16, 2016

Pushed a test commit to try to understand what's going on on the bots.

@brson brson force-pushed the brson:proxy-fix branch from 8cbe1de to c8dec07 Nov 17, 2016

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 17, 2016

OK, I think I've got the test written correctly.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 17, 2016

Legit failures on windows.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 18, 2016

Well, toolchain link seems pretty broken on Windows. I can't get it to work manually. Windows doesn't seem to understand the directory junction. I'm not sure why the rest of the link tests are working.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 18, 2016

I think I'm just going to clean this up and merge the fix for unix, and figure out the windows junction problems later.

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 21, 2016

☔️ The latest upstream changes (presumably #822) made this pull request unmergeable. Please resolve the merge conflicts.

@brson brson force-pushed the brson:proxy-fix branch from 0d82b65 to bb64297 Nov 22, 2016

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 22, 2016

OK, I've got a variation that works on windows now.

Turned out to be 3 bugs preventing linked toolchains from working properly on windows!

First, std's fs::metadata does not follow windows directory junctions as I expected, so the "does this toolchain exist" test always failed, then there was the junction bug @Diggsey fixed, and finally, I had to hack up the fallback code to copy cargo.exe to its own directory before running it - otherwise the windows process lookup order just always runs the rustc.exe next to it and doesn't bother searching the path.

So there's some hacks here.

r? @alexcrichton

} else {
env::args_os().take(1).chain(env::args_os().skip(2)).collect()
env::args_os().skip(2).collect()

This comment has been minimized.

@brson

brson Nov 22, 2016

Author Contributor

These were incidental changes to improve error reporting in the proxies.

@@ -1,8 +1,6 @@
use std::env;

This comment has been minimized.

@brson

brson Nov 22, 2016

Author Contributor

This file is again all just incidental stuff.

@brson brson force-pushed the brson:proxy-fix branch from bb64297 to fa8a05d Nov 22, 2016

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 22, 2016

Well, this doesn't pass the test suite...

Edit: oh, I updated my toolchain and the test suite no longer passes because of assumptions it contained about the relative path between test exes and rustup-init.exe, so the test failures are on my end.

@brson brson force-pushed the brson:proxy-fix branch from fa8a05d to 87d9452 Nov 22, 2016

Recursive tool invocations should invoke the proxy, not the tool dire…
…ctly

The way the proxy was setting up the PATH variable contained two bugs:
first, that it allowed the toolchain path to precede the value of CARGO_HOME/bin;
but second that it didn't add CARGO_HOME/bin to the path at all. The result
was that when e.g. cargo execs rustc, it was directly execing the toolchain
rustc.

Now it execs the proxy, assuming that CARGO_HOME/bin is set up correctly,
and guaranteeing not to run the toolchain tool directly.

Fixes #809

@brson brson force-pushed the brson:proxy-fix branch from 87d9452 to a7cba0c Nov 22, 2016

@alexcrichton
Copy link
Member

alexcrichton left a comment

Seems ok to me, to be honest I'm not really sure what's going on here though. If it fixes things them I'm fine merging.

I guess I always figured that rustup proxies always had the highest priority in PATH and then from those bins we'd delegate further, but maybe that's naive? I also don't understand what a fallback is...

} else {
false
};
utils::is_directory(&self.path) || is_symlink

This comment has been minimized.

@alexcrichton

alexcrichton Nov 22, 2016

Member

Hm I'm somewhat dubious about this change. Perhaps the error is that the call to fs::metadata returns false for is_directory? Couldn't function just be self.path.exists()?

This comment has been minimized.

@alexcrichton

alexcrichton Nov 22, 2016

Member

Er to elaborate, this is fine, but I feel like this is just jumping through too many hoops to conclude that something is a directory when all we're interested in is if a path exists or not.

This comment has been minimized.

@Diggsey

Diggsey Nov 22, 2016

Contributor

@alexcrichton The reason we care that it's a directory is because sometimes extra files get created (think thumbs.db or various dot files) and it's better if rustup doesn't confuse them for toolchains.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 22, 2016

Failure seems bogus.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 22, 2016

I guess I always figured that rustup proxies always had the highest priority in PATH and then from those bins we'd delegate further, but maybe that's naive? I also don't understand what a fallback is...

That's what it should do, yes, and it used to, and this patch makes it do that again.

@brson

This comment has been minimized.

Copy link
Contributor Author

brson commented Nov 22, 2016

The fallback is when rustup uses the nightly (fallback) cargo against a custom toolchain that doesn't contain cargo.

@brson brson merged commit 4d38610 into rust-lang:master Nov 23, 2016

1 of 2 checks passed

continuous-integration/appveyor/pr AppVeyor build failed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@michaelwoerister

This comment has been minimized.

Copy link

michaelwoerister commented Nov 23, 2016

🎉

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Dec 13, 2016

Just logging this because it happened, but I don't think this is something we should change.

I believe this commit broke Cargo's test suite unfortunately. Specifically when cargo is invoked it no longer has the rustc bin directory in PATH. This means that when Cargo during the tests compiles a dynamically linked binary (dynamically against libstd) the binary is unable to actually find the standard library.

I'm... not entirely sure how to fix this, but I'll try to figure something out.

@MoSal

This comment has been minimized.

Copy link

MoSal commented on src/rustup/command.rs in a7cba0c Feb 28, 2017

This line causes a compile failure in latest nightly. s/&args/args fixes it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.