`lto = true` causes dependency rebuilds when alternating `cargo build` and `cargo build --tests`

[jonas-schievink]

Problem

When setting lto = true in the dev profile, Cargo will rebuild all dependencies when switching between cargo build to cargo build --tests (and vice-versa).

Steps

1. Check out https://github.com/jonas-schievink/cargo-lto-bug
2. Run cargo build
3. Run cargo build --tests
4. Observe that Cargo rebuild the bitflags dependency

Notes

Output of cargo version: cargo 1.46.0 (149022b1d 2020-07-17)

Also happens on the current nightly, which is cargo 1.47.0-nightly (51b66125b 2020-08-19)

[ehuss]

Thanks for creating the repro! I did note that this would happen at #8192 (comment), though at the time I was unsure why someone would do that. Is there a particular reason you would run cargo build in an rlib-only project?

One workaround is to also set LTO in [profile.test]. I'm uncertain why you would set LTO in an rlib-only project, though, since it doesn't perform linking.

Another option is that Cargo could include the LTO status in the metadata hash. @alexcrichton, was there a specific reason to only put it in the fingerprint?

[jonas-schievink]

Hmm, this was reduced from https://github.com/knurling-rs/app-template, where I noticed that this would happen when trying to run the tests in testsuite. There, the main package is an rlib, but has optional binaries, so enabling LTO makes sense (as it reduces binary size, and this is a template for embedded projects). I'm not sure which commands you need exactly to reproduce this in the full setting though.

[alexcrichton]

This seems fine to me to inclue the lto setting into the metadata, and seems reasonable to avoid thrashing in a case like this.

[epage]

See also #8762