clippy fails to run with "error[E0463]: can't find crate for std"

[matthiaskrgr]

On my project I run clippy on travis ci
https://github.com/matthiaskrgr/cargo-cache/blob/master/.travis.yml#L87
A few days ago clippy started failing to run with

error[E0463]: can't find crate for `std`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.
error: Could not compile `serde`.
warning: build failed, waiting for other jobs to finish...

without me changing anything on the config.

On december 8 it was still working fine
https://travis-ci.org/matthiaskrgr/cargo-cache/jobs/465214963
On december 9 it started failing to run when being installed from the git repo
https://travis-ci.org/matthiaskrgr/cargo-cache/jobs/465490462

Any ideas what could be the cause of this?

[sinkuu]

I assume this is caused by #3257. rustc_driver's default sysroot is based on env::current_exe() (usually ~/.rustup/toolchains/*/bin/clippy-driver), so it does not work for ~/.cargo/bin/clippy-driver which your travis script installs when the rustup component is unavailable.

[matthiaskrgr]

Ugh so tl;dr: clippy no longer works if manually installed from the git repo? :(

[aldanor]

Just hit this as well, this is extremely confusing.

[matthiaskrgr]

I can't even call it directly from the target dir (target/debug/cargo-clippy)

./target/debug/cargo-clippy 
    Checking matches v0.1.8
error[E0463]: can't find crate for `std`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: Could not compile `matches`.

It's hard to believe we had no regression tests to catch this earlier.

[phansch]

It looks like the integration tests do: https://travis-ci.org/rust-lang/rust-clippy/jobs/467976025#L863 but they fail to fail :/

[matthiaskrgr]

Oh wow ...

[ghost]

It looks like the change isn't going to be reverted. Let's think about alternatives.

How about a feature flag to restore the old behaviour? If you're building it yourself you can just enable the feature.

[oli-obk]

Does it work if you pass --sysroot manually?

If so, you can use RUSTFLAGS=--sysroot=foo cargo clippy on your manually installed clippy.

Autodetection of the sysroot has always been a hack (and has gotten more and more hacks to support every kind of setup out there).

Maybe we should give cargo some sort of support for installing crates into the sysroot?

[ghost]

That works for me.

[matthiaskrgr]

I'm going to revert this tomorrow on the following grounds:

• it has been two weeks since the regression was introduced without a message from the original author
• the regression breaks several use cases and the --sysroot hack requires manual intervention and does not fix the issue inside clippy
• the PR broke 13 of our 15 ci jobs which means we may introduce more regressions without noticing without a fix
• since the PR broke ci, it should have never been merged but we failed to notice due to the way it broke the ci.
• no actual drop-in fix has been supplied yet

[oli-obk]

the regression breaks several use cases and the --sysroot hack requires manual intervention and does not fix the issue inside clippy
no actual drop-in fix has been supplied yet

the --sysroot hack is much less of a hack than what we had before. If anything we should make cargo clippy obtain the sysroot and pass it on to the invocation of clippy-driver instead of having clippy-driver do arbitrary things

since the PR broke ci, it should have never been merged but we failed to notice due to the way it broke the ci.

I thought CI was fixed, sorry. I'm prioritizing this

[mati865]

@oli-obk CI silently failed because of it's a bit hacky as well: #3552

[matthiaskrgr]

No, ci is still not fixed. There's a PR that tweaks ci to catch this in the future though.