-
Notifications
You must be signed in to change notification settings - Fork 892
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
Stop defaulting to $PATH searches when the binary can't be found and causing infinite recursion #917
Conversation
The PATH fallback is important functionality in rustup - it's used whenever using a custom toolchain without cargo, and there are several other cases where you want to run a program in the environment for a particular toolchain. |
I don't see how that ever worked? If you have a toolchain without cargo the PATH fallback will just re-resolve to rustup and go in cycles. This works using env vars so unless we explicitly handle this it won't work. I think we should change this code to explicitly try the default toolchain instead (and emit a warning that it did a fallback), and not do PATH-resolution at all. |
Or, it's only going to work for binaries that themselves don't shell out to rustup. The test that handles this does |
dfda79f
to
5c7c68e
Compare
I made it check the recursion var so that |
Is this what happens when you e.g. grab Rust sources, build your own stage1 compiler from them, and use it as a custom toolchain for building Cargo-based projects? |
That's what should happen, but it doesn't work right now. |
Was on my phone so couldn't give much detail earlier. This is the PR that added the fallback: #822 Thanks for making the change anyway, however I think:
|
It has to be less than 5; since it needs to preempt the regular recursion check. I can make it 4. |
5c7c68e
to
fba34dc
Compare
Can you make it a named constant, use Rustup has a big problem with changes to one aspect of the tool causing problems elsewhere, and the only way it's going to get better is by making dependencies more explicit, and being meticulous about adding regression tests. |
…causing infinite recursion
fba34dc
to
4cacd2e
Compare
This PR looks good to me, but there is a legit test failure. Edit: thanks @Manishearth and @Diggsey |
The test failure arises because we're trying to test what happens when you fallback to the path in a regular install, and the test environment is not a regular install -- it has multiple rustcs (one in the path from Travis, one that goes through rustup). @Diggsey said he'd look into fixing this IIRC. I don't recall what solution we'd come up with. |
@Manishearth sorry, lost track of this - I think I have a better way to get this to work rather than messing too much with the CI environment, I'm just testing it out now. |
I decided to temporarily hardlink a new proxy binary to use for the test. This seems to work for the most part, although some of the linux tests are still failing, as they don't seem to pick it up. |
Yeah that looks like a good fix in the test. Nice thinking. |
Travis has decided not to run my build, and my local reproduction of the problem fixed itself before I even changed anything 😡 Who knows, it might be fixed now... |
I don't think we should ever be falling back to letting the OS resolve on the basis of
$PATH
, but if others still want that functionality I can make this error happen only in the recursion case (whenRUST_RECURSION_COUNT
is 4 or something).Currently if you have a broken toolchain (e.g. a
rustup link
toolchain to an in-progress build directory that doesn't have the executables in it yet) rustup will default to a$PATH
search when it can't find the binary, and this will just resolve back to rustup, which causes the infinite recursion error.Took me a while to figure out that this was a bug with rustup and not my code. Someone else hit it today as well when trying to use rust-gdb, so it might have been introduced recently, though that doesn't seem to be the case.
r? @brson