Change:
} #[test] <del> fn test_externs_tracking_hash_different_values() { let mut v1 = super::basic_options(); let mut v2 = super::basic_options(); let mut v3 = super::basic_options(); v1.externs = Externs::new(mk_map(vec![ (String::from("a"), mk_set(vec![String::from("b"), String::from("c")])), (String::from("d"), mk_set(vec![String::from("e"), String::from("f")])), ])); v2.externs = Externs::new(mk_map(vec![ (String::from("a"), mk_set(vec![String::from("b"), String::from("c")])), (String::from("X"), mk_set(vec![String::from("e"), String::from("f")])), ])); v3.externs = Externs::new(mk_map(vec![ (String::from("a"), mk_set(vec![String::from("b"), String::from("c")])), (String::from("d"), mk_set(vec![String::from("X"), String::from("f")])), ])); assert!(v1.dep_tracking_hash() != v2.dep_tracking_hash()); assert!(v1.dep_tracking_hash() != v3.dep_tracking_hash()); assert!(v2.dep_tracking_hash() != v3.dep_tracking_hash()); // Check clone assert_eq!(v1.dep_tracking_hash(), v1.clone().dep_tracking_hash()); assert_eq!(v2.dep_tracking_hash(), v2.clone().dep_tracking_hash()); assert_eq!(v3.dep_tracking_hash(), v3.clone().dep_tracking_hash()); } #[test] </del> fn test_externs_tracking_hash_different_construction_order() { let mut v1 = super::basic_options(); let mut v2 = super::basic_options();

Discussion:
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata said was the . do you know why this would be? I built this twice in different directories using the script. The diff of the rlib from each build (I generated that using .) Presumably this would block and also
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here:
cc This is similar to the GCC build-path issue where other programs (and in the past, GCC's DWATproducer) likes to embed CFLAGS into the output. Suggested options: out -Zremap-path-prefix away from that SVH calculation - but other programs that also embed RUSTFLAGS or similar, would also need similar logic the envvar or something similar cargo support a constant flag (whose value does not depend on build-path) that figures out the right -Zremap-path-prefix for rustc so they don't need to appear in RUSTFLAGS. you'd also need to implement (1) but at least the caveat (about other programs) doesn't apply.
addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes.
With the latest Rust nightly: which includes the fix from , the outputs from are still not the same:
I think we may still be hashing arguments?
Yes, it seems we do: Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review.
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) still affects the SVH, even if the mapping does nothing: will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes.