Logo
Explore Help
Register Sign In
rust-lang/rust
1
0
Fork 0
You've already forked rust
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
58e901b6fd1163172149fd422565523b17eed5f0
rust/tests/incremental/link_order/main.rs

13 lines
305 B
Rust
Raw Normal View History

Don't sort a `Vec` before computing its `DepTrackingHash` 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.
2021-05-25 19:43:02 -05:00
// aux-build:my_lib.rs
// error-pattern: error: linking with
// revisions:cfail1 cfail2
// compile-flags:-Z query-dep-graph
// Tests that re-ordering the `-l` arguments used
// when compiling an external dependency does not lead to
// an 'unstable fingerprint' error.
extern crate my_lib;
fn main() {}
Reference in New Issue Copy Permalink
Powered by Gitea Version: 1.24.6 Page: 959ms Template: 3ms
English
Bahasa Indonesia Deutsch English Español Français Gaeilge Italiano Latviešu Magyar nyelv Nederlands Polski Português de Portugal Português do Brasil Suomi Svenska Türkçe Čeština Ελληνικά Български Русский Українська فارسی മലയാളം 日本語 简体中文 繁體中文(台灣) 繁體中文(香港) 한국어
Licenses API