Derive Ord, PartialOrd and Hash for SocketAddr*

[WaffleLapkin]

Fixes #116711

The main pain of this PR is to fix the buggy impl of Ord for SocketAddrV6, which ignored half of the fields (while PartialEq is derived):

rust/library/core/src/net/socket_addr.rs

Lines 99 to 106 in 4603f0b

	#[derive(Copy, Clone, Eq, PartialEq)]
	#[stable(feature = "rust1", since = "1.0.0")]
	pub struct SocketAddrV6 {
	ip: Ipv6Addr,
	port: u16,
	flowinfo: u32,
	scope_id: u32,
	}

rust/library/core/src/net/socket_addr.rs

Line 676 in 4603f0b

self.ip().cmp(other.ip()).then(self.port().cmp(&other.port()))

For me it looks like a simple copy-paste error made in #72239 (copy from v4 impl) (cc @hch12907), as I don't see this behavior being mentioned anywhere on the PR and it also does not respect cmp trait "rules". I also do not see any reasons for those impls to not be derived.

It's a shame we did not notice this for 28 versions/3 years. I guess this is a bug fix, but I'm not sure what the process here should be.

r? libs

[workingjubilee]

Note that this does not change whether there is an impl insofar as I can see, but they do change the implementation's behavior.

[WaffleLapkin]

Yes, the only functional change is SocketAddrV6::{cmp,partial_cmp} also considering flowinfo and scope_id fields. No impls are removed.

[hch12907]

As the original author of #72239 - this change makes sense.

But I have a question: does it make sense to include flowinfo? Unlike the other fields which are fairly fixed, the flow label is "a high-entropy identifier of a flow of packets between a source and destination" (according to wiki).

I also do not see any reasons for those impls to not be derived.

Note that SocketAddrV{4,6} were originally just a wrapper of sockaddr_in{,6} from libc. From memory, sockaddr_in{,6} did not implement (Partial)Ord which was why a simple #[derive] was not possible.

[workingjubilee]

A flow label is assigned to a flow by the flow's source node. New
flow labels must be chosen (pseudo-)randomly and uniformly from the
range 1 to FFFFF hex. The purpose of the random allocation is to
make any set of bits within the Flow Label field suitable for use as
a hash key by routers, for looking up the state associated with the
flow.

All packets belonging to the same flow must be sent with the same
source address, destination address, and flow label.¹

So... I think probably yes?

Footnotes

1. IETF RFC 2460 ↩

[hch12907]

Looks good to me.

[joshtriplett]

@bors r+ rollup

[bors]

📌 Commit 5c13c69 has been approved by joshtriplett

It is now in the queue for this repository.

[joshtriplett]

Merging per review in libs-api meeting.