Modifying RUSTFLAGS should not invalidate the already built artifacts

[jonas-schievink]

Problem

It looks like changing RUSTFLAGS (or, more likely, the rustflags key in .cargo/config) will currently recompile all dependencies with the new flags (which is fine) and invalidate/overwrite the already built artifacts with the older RUSTFLAGS value.

This is causing significant pain for me as I work on a project that has multiple workspace members that define their own .cargo/config with different rustflags. This is an embedded project, an RTOS consisting of kernel and userspace binaries, to be precise, so rustflags/linker shenanigans are somewhat expected.

This issue causes a kernel build to invalidate all userspace artifacts and vice-versa, which makes development sufficiently painful that we're not using a Cargo workspace at all (breaking IDE integration in the process). Having multiple target directories of course will work around the issue, but is less than ideal.

Steps

Unfortunately the code base is not yet open-sourced, but I can try to provide a minimal example if requested.

Possible Solution(s)

The old artifacts should be reused when RUSTFLAGS is changed back to the original value.

Notes

Output of cargo version: cargo 1.42.0-nightly (86134e766 2019-12-23)

[alexcrichton]

This was first implemented in #6503 but was reverted in #7417, so I'm going to close this since it's an explicit design decision now to have RUSTFLAGS overwrite artifacts.

[jonas-schievink]

What's the recommended way to develop in a workspace like this then? Just don't use a Cargo workspace?

Regarding #7416, it seems to me that there are multiple interacting things at play here:

• Cargo has no built-in understanding of PGO, so the only way to use it is via RUSTFLAGS
• RUSTFLAGS does not just overwrite compiled artifacts, but also changes symbol names via -Cmetadata – it makes sense to me that these are sometimes connected, but as you said in Go back to not hashing RUSTFLAGS in -Cmetadata #7417 some changes in compiler options don't need to change every symbol name

It seems like a very drastic measure to forego caching entirely just to avoid influencing symbol names. Is it not possible to decouple these effects?

[alexcrichton]

I think using a workspace is fine you may just want to use different target directories to keep the caches in different locations. If you're already using .cargo/config for rustflags you should be able to use that for target directories as well.

I think it's fine to propose changes, but a proposal to change deliberate behavior in Cargo today should take into account why Cargo is the way it is.