Am I expecting too much from cargo or is it a bug?
After trying to build exa with too old a version of rustc, I switched to the current nightly and started from a clean source directory - the build failed exactly as before. Manually clearing the cache helped but I'm not sure from reading the help if 'cargo update' was the way to go? (clean doesn't help)
EDIT:
Even though multirust would solve this (or simply a different CARGO_HOME) - I meant why is cargo blindly using some prebuilt stuff when the project never finished building successfully? I was expecting a full overwrite of old stuff upon detecting a compiler change.
Unfortunately the compiler cannot reliably use artifacts from older or newer versions of the compiler, it can only use artifacts which it itself produced (or some other rustc on the same hash). Does that explain the behavior you see here? Unfortunately I'm not quite sure what the disconnect is here between what you saw and what you expected to see, perhaps you could elaborate?
1 Like
Yes, that explains it well and corresponds to what I saw, thanks 
I was slightly surprised that the artifacts from that one crate that didn't finish building successfully (and it wasn't the first!) were still being used even on compiler change.
I'm probably imagining this:
on cargo build, when the detected version of rustc differs from the one cached, it would clear everything related to the project. Eventually it would mean overwriting all revisited artifacts and the user wouldn't have to bother about the .cargo contents.
We're talking about a permanent rustc upgrade use case and not using multiple versions concurrently.
1 Like
That's effectively what Cargo should be doing, did you find that Cargo didn't rebuild some crates when switching rustc versions when it should?
In that case it felt wrong from the start and quite rightly so! 
Yes, that was my experience with the scoped_threadpool crate while building exa. After switching to the recommended nightly all crates before this one were (re)built fine but not scoped_threadpool again.
Hm interesting! Is there a way that I could reproduce this behavior locally?
All I did trying to build exa was use x86 rustc-1.3.0 and cargo from 1-2 weeks ago, then switch to 1.5.0 nightly (in a new exa source directory).
The only part I'm not sure about (probably shouldn't matter) is whether the cargo binary(ies) used, both had debugging enabled (my first cargo build did) as I updated cargo as well somewhere in-between.
I still have the original .cargo directory in case you can't reproduce so I could probably upload the interesting parts.
Here's the exact reproduction:
cargo build --release --verbose
Fresh pkg-config v0.3.5
Fresh winapi v0.2.4
Fresh byteorder v0.3.13
Fresh winapi-build v0.1.1
Fresh regex-syntax v0.2.2
Fresh semver v0.1.20
Fresh rustc-serialize v0.3.16
Fresh bitflags v0.1.1
Fresh matches v0.1.2
Fresh unicode-width v0.1.3
Fresh ansi_term v0.5.2
Fresh natord v1.0.9
Fresh libc v0.1.10
Fresh getopts v0.2.14
Fresh tz v0.2.1
Fresh rustc_version v0.1.2
Compiling scoped_threadpool v0.1.6
Running `/home/petevine/exa-master/target/release/build/scoped_threadpool-3092426cc5b469bd/build-script-build`
Fresh url v0.2.37
Fresh term_grid v0.1.2
Fresh pad v0.1.4
Fresh users v0.4.3
Fresh memchr v0.1.6
Fresh num_cpus v0.2.6
Compiling gcc v0.3.15
Running `rustc /home/petevine/.cargo/registry/src/github.com-121aea75f9ef2ce2/gcc-0.3.15/src/lib.rs --crate-name gcc --crate-type lib -C opt-level=3 -C metadata=41c787e814e6c729 -C extra-filename=-41c787e814e6c729 --out-dir /home/petevine/exa-master/target/release/deps --emit=dep-info,link -L dependency=/home/petevine/exa-master/target/release/deps -L dependency=/home/petevine/exa-master/target/release/deps --cap-lints allow`
Compiling rand v0.3.11
Running `rustc /home/petevine/.cargo/registry/src/github.com-121aea75f9ef2ce2/rand-0.3.11/src/lib.rs --crate-name rand --crate-type lib -C opt-level=3 -C metadata=a5a71c849766362c -C extra-filename=-a5a71c849766362c --out-dir /home/petevine/exa-master/target/release/deps --emit=dep-info,link -L dependency=/home/petevine/exa-master/target/release/deps -L dependency=/home/petevine/exa-master/target/release/deps --extern advapi32=/home/petevine/exa-master/target/release/deps/libadvapi32-e22807087253781e.rlib --extern libc=/home/petevine/exa-master/target/release/deps/liblibc-165b5479aec0459c.rlib --extern winapi=/home/petevine/exa-master/target/release/deps/libwinapi-3afcd2170e6034e1.rlib --cap-lints allow`
Fresh aho-corasick v0.3.2
Build failed, waiting for other jobs to finish...
failed to run custom build command for `scoped_threadpool v0.1.6`
Process didn't exit successfully: `/home/petevine/exa-master/target/release/build/scoped_threadpool-3092426cc5b469bd/build-script-build` (exit code: 101)
--- stderr
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:365