Changing cfg_test may lead to using stale dependent crate types in workspace

rust-lang / rls

Repository for the Rust Language Server (aka RLS)

Other

3.51k stars 257 forks source link

Changing cfg_test may lead to using stale dependent crate types in workspace #362

Open Xanewok opened 7 years ago

Xanewok commented 7 years ago

Currently the problem only affects a simple bin/lib project scenario, but I think it's more general than that. Since the cfg_test switch is only on RLS side, when we change it and request complete analysis at startup from Cargo, it doesn't see any expected change in behaviour (presumably because target fingerprint is unchanged?) and uses previously compiled dependencies (with old cfg_set setting for compilation), which may lead to weird analysis inconsistencies when compiling final crate type.

nrc commented 7 years ago

Do you have a test case that can reproduce this? I'm a bit concerned that we might forget about this, but it doesn't seem very actionable at the moment.

Xanewok commented 7 years ago

IIRC you could theoretically, when analyzing a bin/lib project:

set cfg_test = false and build_lib = false
wait for the analysis to complete
restart with cfg_test = true
When analysing the bin, Cargo thinks lib is up to date, so it doesn't rebuild it (because of fingerprints, as RLS flags are not a part of Cargo fingerprint metadata, however it should be rebuilt because of different cfg)

I'll have to check again and can get back with a simple repro.