0.0.105 doesn't work at all on windows 10/msvc target/rust 1.16.0-nightly 2017-01-03

[radix]

I just updated rust nightly and ran cargo install clippy. Whereas before cargo clippy would print an error about how there is no clippy subcommand, now it exits very quickly without printing anything to the screen. Likewise for cargo clippy --help and cargo clippy --version.

On Powershell, $lastExitCode is being set to the rather weird value -1073741515. (for comparison, when I run e.g. a cargo build command with broken rust source code, I get a $lastExitCode of 101). In git-shell (bash), $? is being set to "False". I'm new to this windows stuff so I'm not really sure what the significance of that large negative number is.

[Manishearth]

I suspect that cargo install borked something there. Try again, with cargo install clippy -f?

(It works for me locally)

[radix]

sadly a reinstall (or, actually, an upgrade to the just-released 0.0.106) didn't fix the problem:

C:\Users\radix\Projects\pandt [rust ↑ +0 ~2 -0 !]> cargo install clippy -f
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading clippy v0.0.106
 Downloading clippy_lints v0.0.106
   Compiling unicode-normalization v0.1.3
   Compiling nom v1.2.4
   Compiling quine-mc_cluskey v0.2.4
   Compiling matches v0.1.4
   Compiling regex-syntax v0.3.9
   Compiling rustc-serialize v0.3.22
   Compiling semver v0.2.3
   Compiling toml v0.1.30
   Compiling clippy_lints v0.0.106
   Compiling clippy v0.0.106
    Finished release [optimized] target(s) in 102.10 secs
   Replacing C:\Users\radix\.cargo\bin\cargo-clippy.exe
C:\Users\radix\Projects\pandt [rust ↑ +0 ~3 -0 !]> cargo clippy ueoaueoa
C:\Users\radix\Projects\pandt [rust ↑ +0 ~3 -0 !]> cargo clippy
C:\Users\radix\Projects\pandt [rust ↑ +0 ~3 -0 !]> cargo clippy --help
C:\Users\radix\Projects\pandt [rust ↑ +0 ~3 -0 !]> echo $LASTEXITCODE
-1073741515

[Manishearth]

huh. no idea what can cause that.

[Arnavion]

-1073741515 means it can't find a DLL. Make sure the directory containing the rust DLLs is in your PATH. Eg C:\Users\Arnavion\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin

[radix]

@Arnavion Good catch, that does seem to be the problem. So the question is... whose fault is it that that path isn't on my environment when cargo gets run? To be certain that it's the default behavior, I completely scrapped all of my rust installation (~/.cargo, ~/.multirust, and ~/.rustup), and reinstalled rustup from scratch, and switched to nightly-msvc as the default. Then I installed clippy the usual way and the problem persists.

Should rustup be putting that toolchain-specific bin path on my PATH, or is it the user's responsibility?

[Arnavion]

Yes, the default behavior is that rustup does not include that directory in the PATH for subcommands subprocesses. When I found this out I resorted to just putting the bin path of every toolchain (stable, nightly, local) that I use in my PATH. Atleast it was only a one-time thing.

[kornholi]

Ran into this as well. Related: rust-lang/cargo#3394

[starkat99]

After installing the clippy subcommand with cargo run nightly cargo install clippy, if I run clippy using rustup run nightly cargo clippy I get a string of dialog errors like the following:

[gcp]

Visual Studio Code is showing clippy as erroring out with "Completed with code 3221225781". I assume that's the same issue. Installed nightly/clippy/source via rustup, Win10, MSVC.

[Arnavion]

3221225781 is the same as -1073741515, yes (both are 0xC0000135).

[oli-obk]

we could make cargo clippy an intermediate that does not depend on rustc libraries, looks for them and runs the actual cargo clippy with the PATH set correctly. But it would be simpler if rust-lang/cargo#3394 were fixed.

[aleksanb]

This bug seems to be present still on Windows 10, when invoking cargo clippy in powershell.
clippy v0.0.137.
Exit code: -1073741515.
rustup 1.3.0 (124170c 2017-05-09)
rustc 1.19.0-nightly (6684d17 2017-06-03)

[flip1995]

I think we can close this issue. This is long outdated and we haven't seen bugs like this for a long time.