interaction with sccache changed, all deps rebuilt when calling "cargo build" twice

[matthiaskrgr]

cargo 1.36.0-nightly (c4fcfb725 2019-05-15)
release: 1.36.0
commit-hash: c4fcfb725b4be00c72eb9cf30c7d8b095577c280
commit-date: 2019-05-15

When using sccache (via RUSTC_WRAPPER), running cargo build ; cargo build will cause all dependencies to be rebuilt even if nothing changed between the two "cargo build" runs.
(I'm not very sure what is actually happening, since the second run is consistently faster than the first run)

cargo clean ; cargo build ; cargo build

   Compiling serde v1.0.80
   Compiling ryu v0.2.7
   Compiling itoa v0.4.3
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 4.43s
   Compiling itoa v0.4.3
   Compiling serde v1.0.80
   Compiling ryu v0.2.7
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 1.48s

This is not the case when sccache is not used or when RUSTC_WRAPPER is unset:

   Compiling serde v1.0.80
   Compiling ryu v0.2.7
   Compiling itoa v0.4.3
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 11.65s
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s

According to my bisect, 6b28a0c is the commit that caused this strange behaviour.

[matthiaskrgr]

Just to be clear, the ticket is about none-pipelined compilation (unless there is something that turned it on by default that I missed).

[tesuji]

Is this related to #6978 ?

[alexcrichton]

I was personally unable to reproduce this yesterday, @matthiaskrgr can you detail how to reproduce this? (for example what version of sccache, what project, perhaps a minimal example, etc)

[ehuss]

I'm able to reliably reproduce it. I'm fairly certain this is because Cargo is now producing both rlib and rmeta files, even when pipelining is not enabled. Sometimes sccache detects it (presumably some kind of race?), but usually the rmeta files don't get created. I would think this issue needs to be filed on sccache? Unless @alexcrichton wants to change it so that Cargo can handle rmeta files mysteriously disappearing (EDIT: though I don't think it would be a good idea, it would complicate pipelining I would think). There was a similar issue in the Clippy repo where it was deleting rmeta files, causing everything to be rebuilt (already fixed rust-lang/rust-clippy#4115).

[matthiaskrgr]

I use sccache from the git repo https://github.com/mozilla/sccache , commit ce983d5d1b8d35c71e6b99a6a9b17ed17a6dad1a
build it in release mode and copy it into ~/.cargo/bin/

I have RUSTC_WRAPPER set as /home/matthias/.cargo/bin/sccache

I can repro for example building https://github.com/serde-rs/json at 5b5f95831d9e0d769367b30b76a686339bffd209

 matthias@t470  ~/vcs/github/serde_json   master  cargo build
   Compiling ryu v0.2.7
   Compiling serde v1.0.80
   Compiling itoa v0.4.3
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 4.16s
 matthias@t470  ~/vcs/github/serde_json   master  cargo build
   Compiling itoa v0.4.3
   Compiling ryu v0.2.7
   Compiling serde v1.0.80
   Compiling serde_json v1.0.39 (/home/matthias/vcs/github/serde_json)
    Finished dev [unoptimized + debuginfo] target(s) in 1.13s

[alexcrichton]

Ah thanks for confirming @ehuss and for the extra info @matthiaskrgr. If this is an issue with sccache then I think yeah we can move it to that repository, and it sounds like that's the case?

[luser]

I looked into this briefly and found that sccache isn't caching the rmeta outputs, but there's an existing workaround that pointed to rust-lang/rust#54852 and testing shows that rustc does not in fact list the rmeta filename when calling it with --print=file-names, so that is likely the underlying issue!

[matthiaskrgr]

This has been fixed on the sccache side 👍