switch between nightly and stable causes buildfailure

[drahnr]

cargo +nightly b after accidentally running cargo b where the default toolchain is stable

   Compiling unicase v1.4.2
error[E0514]: found crate `rustc` compiled by an incompatible version of rustc
 --> /home/bernhard/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/unicase-1.4.2/build.rs:1:1
  |
1 | extern crate version_check as rustc;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = help: please recompile that crate using this compiler (rustc 1.37.0-nightly (9606f6fa6 2019-06-14))
  = note: the following crate versions were found:
          crate `rustc` compiled by rustc 1.35.0 (3c235d560 2019-05-20): /home/bernhard/Projects/rhapsodize/target/debug/deps/libversion_check-b81766fb0f808cf7.rlib

error: aborting due to previous error

error: Could not compile `unicase`.

The quick solution is to delete referenced rlib files, I am also not sure if this is related to sccache at all.
warning: build failed, waiting for other jobs to finish...
error: build failed

[drahnr]

Going to be solved by #666

[repi]

Did it solve it? Been merged but this is still open.

Would that also solve the case of switching between two different nightly versions (same version number, different date)?

[drahnr]

It is indeed solved and can be closed.

[repi]

Sweet! Thx

[drahnr]

@repl note that you need to flush your cache (redis, memcached or whatever backend you are using) - wrongly versioned binary artifacts are still cached there which will cause you to see errors until they are removed.
And also remove the locally cached version rm -rf ~/.cache/sccache-* if you are using the dist-client feature.
And last but not least, do the same for your projects ./target dir which at this point is likely to contain copies of the remotely cached artifacts.

---

Alternatively SCCACHE_RECACHE=1 and delete ./target dir.

[repi]

Ah thanks for the heads up!

[repi]

We upgraded to f502075 on master and flushed our sccache data and target/ but are still seeing build failures related to sccache when our CI switches to a new nightly build:

error[E0514]: found crate `futures_core` compiled by an incompatible version of rustc
  --> /usr/local/cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/futures-channel-0.3.5/src/mpsc/mod.rs:81:5
   |
81 | use futures_core::stream::{FusedStream, Stream};
   |     ^^^^^^^^^^^^
   |
   = help: please recompile that crate using this compiler (rustc 1.45.0-nightly (ed084b0b8 2020-05-15))
   = note: the following crate versions were found:
           crate `futures_core` compiled by rustc 1.45.0-nightly (769d12eec 2020-05-12): /var/buildkite/builds/embark-studios/ark/target/debug/deps/libfutures_core-9cd068e3b6544207.rmeta

@drahnr any ideas of what else could be incorrect?

[drahnr]

As a matter of fact, testing focused on switching between stable and nightly, I'll give it a shot soon and post the shell helper function I use to wipe sccache

[drahnr]

@repi did not get around to looking into it any futher, this is my cleanup helper:

function cachewipe {
    killall sccache
    rm -r ./target || true
    rm -r ~/.cache/sccache* || true
    redis-cli -u redis://1.2.3.4:6379/2 flushall || true
    export SCCACHE_RECACHE=1
}

followed by cargo b usually does the trick

[repi]

We use a GCS bucket for our sccache storage, which we've wiped manually and works, but as there are nightly releases every few days or so this gets tricky as every update would need a full cache wipe.

[drahnr]

The above should really only be necessary once - from pre #666 to post #666 - I am hopefully going to get around to test this soon

[froydnj]

The above should really only be necessary once - from pre #666 to post #666 - I am hopefully going to get around to test this soon

Wait, why is it even necessary in the first place?

[drahnr]

@repl a colleague just provided me a way of reproducing it could you please attach some open logs, the mention reproduction was caused by an outdated 0.2.13 release
@froydnj frankly I don't remember why, could have been just coincidence that it never happened ever after I did that?

[drahnr]

Tried to reproduce this today, to no avail. Logs would be much appreciated or at least a command sequence consistently reproducing the issue.