@@ -31,59 +31,9 @@ impl SourceKind {
31
31
}
32
32
}
33
33
34
- /// Note that this is specifically not derived on `SourceKind` although the
35
- /// implementation here is very similar to what it might look like if it were
36
- /// otherwise derived.
37
- ///
38
- /// The reason for this is somewhat obtuse. First of all the hash value of
39
- /// `SourceKind` makes its way into `~/.cargo/registry/index/github.com-XXXX`
40
- /// which means that changes to the hash means that all Rust users need to
41
- /// redownload the crates.io index and all their crates. If possible we strive
42
- /// to not change this to make this redownloading behavior happen as little as
43
- /// possible. How is this connected to `Ord` you might ask? That's a good
44
- /// question!
45
- ///
46
- /// Since the beginning of time `SourceKind` has had `#[derive(Hash)]`. It for
47
- /// the longest time *also* derived the `Ord` and `PartialOrd` traits. In #8522,
48
- /// however, the implementation of `Ord` changed. This handwritten implementation
49
- /// forgot to sync itself with the originally derived implementation, namely
50
- /// placing git dependencies as sorted after all other dependencies instead of
51
- /// first as before.
52
- ///
53
- /// This regression in #8522 (Rust 1.47) went unnoticed. When we switched back
54
- /// to a derived implementation in #9133 (Rust 1.52 beta) we only then ironically
55
- /// saw an issue (#9334). In #9334 it was observed that stable Rust at the time
56
- /// (1.51) was sorting git dependencies last, whereas Rust 1.52 beta would sort
57
- /// git dependencies first. This is because the `PartialOrd` implementation in
58
- /// 1.51 used #8522, the buggy implementation, which put git deps last. In 1.52
59
- /// it was (unknowingly) restored to the pre-1.47 behavior with git dependencies
60
- /// first.
61
- ///
62
- /// Because the breakage was only witnessed after the original breakage, this
63
- /// trait implementation is preserving the "broken" behavior. Put a different way:
64
- ///
65
- /// * Rust pre-1.47 sorted git deps first.
66
- /// * Rust 1.47 to Rust 1.51 sorted git deps last, a breaking change (#8522) that
67
- /// was never noticed.
68
- /// * Rust 1.52 restored the pre-1.47 behavior (#9133, without knowing it did
69
- /// so), and breakage was witnessed by actual users due to difference with
70
- /// 1.51.
71
- /// * Rust 1.52 (the source as it lives now) was fixed to match the 1.47-1.51
72
- /// behavior (#9383), which is now considered intentionally breaking from the
73
- /// pre-1.47 behavior.
74
- ///
75
- /// Note that this was all discovered when Rust 1.53 was in nightly and 1.52 was
76
- /// in beta. #9133 was in both beta and nightly at the time of discovery. For
77
- /// 1.52 #9383 reverted #9133, meaning 1.52 is the same as 1.51. On nightly
78
- /// (1.53) #9397 was created to fix the regression introduced by #9133 relative
79
- /// to the current stable (1.51).
80
- ///
81
- /// That's all a long winded way of saying "it's weird that git deps hash first
82
- /// and are sorted last, but it's the way it is right now". The author of this
83
- /// comment chose to handwrite the `Ord` implementation instead of the `Hash`
84
- /// implementation, but it's only required that at most one of them is
85
- /// hand-written because the other can be derived. Perhaps one day in
86
- /// the future someone can figure out how to remove this behavior.
34
+ // The ordering here is important for how packages are serialized into lock files.
35
+ // We implement it manually to callout the stability guarantee.
36
+ // See https://github.com/rust-lang/cargo/pull/9397 for the history.
87
37
impl Ord for SourceKind {
88
38
fn cmp ( & self , other : & SourceKind ) -> Ordering {
89
39
match ( self , other) {
0 commit comments