Devirtualized file names interact badly with incremental compilation

[Aaron1011]

We we import SourceFiles from a foreign crate, we try to 'devirtualize' paths pointing into the standard library crates. However, this only occurs if the user has the Rust source available locally (through the rust-src component):

rust/compiler/rustc_metadata/src/rmeta/decoder.rs

Lines 1614 to 1625 in 5e65467

	let virtual_rust_source_base_dir = option_env!("CFG_VIRTUAL_RUST_SOURCE_BASE_DIR")
	.map(Path::new)
	.filter(|_| {
	// Only spend time on further checks if we have what to translate *to*.
	sess.real_rust_source_base_dir.is_some()
	})
	.filter(|virtual_dir| {
	// Don't translate away `/rustc/$hash` if we're still remapping to it,
	// since that means we're still building `std`/`rustc` that need it,
	// and we don't want the real path to leak into codegen/debuginfo.
	!sess.opts.remap_path_prefix.iter().any(|(_from, to)| to == virtual_dir)
	});

The filename ends up getting hashed in the HashStable impl for Span. This means that the Fingerprint of a Span we load from another crate can change across compilation sessions, depending on whether or not the rust-src component is present.

[Aaron1011]

Addressed by a combination of #84233 and #83813