Should CARGO_ env vars be hashed at all?

[kornelski]

sccache treats CARGO_ env vars specially, and includes them in the hash. However, there are variable that are irrelevant for the output, but can break caching:

sccache/src/compiler/rust.rs

Lines 1517 to 1530 in d4ae480

	if !var.starts_with("CARGO_") {
	continue;
	}
	// CARGO_MAKEFLAGS will have jobserver info which is extremely non-cacheable.
	// CARGO_REGISTRIES_*_TOKEN contains non-cacheable secrets.
	// Registry override config doesn't need to be hashed, because deps' package IDs
	// already uniquely identify the relevant registries.
	// CARGO_BUILD_JOBS only affects Cargo's parallelism, not rustc output.
	if var == "CARGO_MAKEFLAGS"
	|| var.starts_with("CARGO_REGISTRIES_")
	|| var == "CARGO_BUILD_JOBS"
	{
	continue;

and there's lot more to exclude:

• CARGO_BUILD_JOBS – concurrency does not affect results
• CARGO_REGISTRY_* – same as CARGO_REGISTRIES_* (random tokens, redundant with package IDs)
• CARGO_TARGET_DIR – already included in the file paths
• CARGO_BUILD_BUILD_DIR
• CARGO_BUILD_TARGET_DIR
• CARGO_HTTP_* – no effect on the outputs
• CARGO_NET_*
• CARGO_TERM_*
• CARGO_ALIAS_*
• CARGO_CACHE_AUTO_CLEAN_FREQUENCY"

and I'm wondering what even is needed to be included?

The problem is that CARGO_ env vars that modify config are only one of multiple ways of modifying Cargo's config. So either sccache is not properly capturing the config set via config.toml or CLI flags, or the config overrides via env vars are redundant. I think they are redundant, as long as the rlib metadata hash is included, and possibly extra-filename set by Cargo. If Cargo's hash put in the rlib filenames is good enough for Cargo, it should be good enough for sccache?

[Xuanwo]

Yep, I think it's fair to remove unrelated cargo envs.

[kornelski]

What about removing all cargo envs?

For example, hashing CARGO_HOME tells you where it is, but doesn't tell you what's in $CARGO_HOME/config.toml. So the env var won't change if the config changes, and OTOH the env var may differ between builds, but the builds can end up using the same config anyway.

Builds with CARGO_INCREMENTAL=0 set hash to a different hash than builds with CARGO_PROFILE_RELEASE_INCREMENTAL=0, even though that's the same thing when building with --release. And they all hash to something else when using [profile.release] incremental = 0 to set it, and not env vars. Or when running cargo b --release --config profile.release.incremental=0 which doesn't set the env vars, but does change the config without modifying any files on disk.

[weihanglo]

Posted a less controversial one: #2651. My initial intent is to stop caching --remap-path-prefix which tend to have absolute paths.