bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity

Don't sort a Vec before computing its DepTrackingHash

Browse source 
Previously, we sorted the vec prior to hashing, making the hash
independent of the original (command-line argument) order. However, the
original vec was still always kept in the original order, so we were
relying on the rest of the compiler always working with it in an
'order-independent' way.

This assumption was not being upheld by the `native_libraries` query -
the order of the entires in its result depends on the order of entries
in `Options.libs`. This lead to an 'unstable fingerprint' ICE when the
`-l` arguments were re-ordered.

This PR removes the sorting logic entirely. Re-ordering command-line
arguments (without adding/removing/changing any arguments) seems like a
really niche use case, and correctly optimizing for it would require
additional work. By always hashing arguments in their original order, we
can entirely avoid a cause of 'unstable fingerprint' errors.
This commit is contained in:
Aaron Hill 2021-05-25 19:43:02 -05:00
parent ff2c947c00
commit 605513a513
No known key found for this signature in database
GPG key ID: B4087E510E98B164
4 changed files with 31 additions and 30 deletions
Download patch file Download diff file Expand all files Collapse all files

10
compiler/rustc_interface/src/tests.rs
View file

@ -252,7 +252,8 @@ fn test_lints_tracking_hash_different_construction_order() {
(String::from("d"), Level::Forbid),
];
assert_same_hash(&v1, &v2);
// The hash should be order-dependent
assert_different_hash(&v1, &v2);
}
#[test]
@ -491,9 +492,10 @@ fn test_native_libs_tracking_hash_different_order() {
},
];
assert_same_hash(&v1, &v2);
assert_same_hash(&v1, &v3);
assert_same_hash(&v2, &v3);
// The hash should be order-dependent
assert_different_hash(&v1, &v2);
assert_different_hash(&v1, &v3);
assert_different_hash(&v2, &v3);
}
#[test]