ghost
commented
5 years ago Closed ghost closed 3 years ago
ghost
commented
5 years ago ghost
commented
5 years ago In other words: if I cargo install before cargo test --release, I get the fail from OP, because for some reason each generates its own (at least)serde-derive crate, and the cargo test then fails. But a re-run of cargo install won't fail. It's only cargo test --release. Note that cargo install implies --release, therefore I feel like I should be testing the cargo test without --release too(in my next comment), just in case the --release one is the cause of the second generation of serde-derive, or wut.
oli-obk
commented
5 years ago Yea this is a known problem with compiletest. I don't think we can do anything on this end other than running a clean.
mati865
commented
5 years ago ghost
commented
5 years ago And so here goes nothing (cargo test without --release, at least it should be in its own debug dir, right?), this was done right after the above ended:
Result: it works!
So I'm guessing if I do cargo build (aka debug because it doesn't have --release) and then I re-run this cargo test (without --release) it should fail like in OP again (minus the release part)
Nope, I was wrong. No effect with debug build.
Ok, so it only happens for release:
Retrying here with a cargo clean: tbd
ghost
commented
5 years ago Due to a github feature :D (probably char limit) my latest edit for the above comment is not in effect, but the changes/contents of it can be seen in the latest edit diff (click edited then most recent, the expand the Details on the right of the vertial green bar)
Anyway, to summarize:
Issue is caused by:
cargo clean then cargo install --path . --force followed by cargo test --release
Issue is not caused by either of:
cargo install --path . --force followed by cargo testcargo clean then cargo build --release followed by either cargo test --release or cargo testcargo clean then cargo build followed by either cargo test --release or cargo testBonus: if never ran cargo install --path . --force after the cargo clean then running cargo check before any of the cargo test or cargo test --release does not cause the issue. (so it's unlike issue https://github.com/rust-lang/rust-clippy/issues/2896 and potentially https://github.com/laumann/compiletest-rs/issues/101#issuecomment-364865869 )
In other words, it's cargo install --path . --force that's the initiatiator...
Pointing back to the aforementioned real cause: https://github.com/rust-lang/rust-clippy/issues/3643#issuecomment-452266854
ghost
commented
5 years ago Here's the question though: why does cargo install --path . --force have to (re)build anything? Assuming it's run after a cargo build --release (the same is true for cargo install --path . --force --debug and cargo build)
look what it (re)builds:
and then if I re-run cargo build --release then this one rebuilds what the install "broke" earlier, presumably:
Having applied https://github.com/rust-lang/rust/pull/57435 manually (since it's not yet merged), and I don't know if this matters at all, I am hitting this issue locally (with clippy HEAD and rustc HEAD compiled with
debug-assertions = true), as follows:Similar issue but for
serdenotserde-deriveis: https://github.com/rust-lang/rust-clippy/issues/2896