Skip to content

Commit d8b7c07

Browse files
committed
shortening the comment
1 parent dd59760 commit d8b7c07

File tree

3 files changed

+5
-55
lines changed

3 files changed

+5
-55
lines changed

Cargo.lock

Lines changed: 1 addition & 1 deletion
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

crates/cargo-util-schemas/Cargo.toml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
[package]
22
name = "cargo-util-schemas"
3-
version = "0.7.2"
3+
version = "0.7.3"
44
rust-version = "1.83" # MSRV:1
55
edition.workspace = true
66
license.workspace = true

crates/cargo-util-schemas/src/core/source_kind.rs

Lines changed: 3 additions & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -31,59 +31,9 @@ impl SourceKind {
3131
}
3232
}
3333

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.
8737
impl Ord for SourceKind {
8838
fn cmp(&self, other: &SourceKind) -> Ordering {
8939
match (self, other) {

0 commit comments

Comments
 (0)