Use DisplayBuffer for socket addresses.

[reitermarkus]

Continuation of #100625 for socket addresses.

Renames net::addr to net::addr::socket, net::ip to net::addr::ip and net::ip::display_buffer::IpDisplayBuffer to net::addr::display_buffer::DisplayBuffer.

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[reitermarkus]

r? @thomcc

[thomcc]

Can you add tests covering long addresses? E.g. ones that would catch an issue if the length used by the DisplayBuffers were wrong? It doesn't seem like we have these.

---

Also, to be clear (since it's not clear from the PR description), none of the renamed things are public API, this modifies internal stuff only.

That said, the renames are probably not that well motivated (since DisplayBuffer is plausibly more broadly useful than just here, and if we moved it elsewhere the module structure here would be slightly goofy), but I don't think it matters that much.

[reitermarkus]

I added some tests for short and long addresses.

the renames are probably not that well motivated

the module structure here would be slightly goofy

I think addr::socket::SocketAddr and addr::ip::IpAddr makes more sense than addr::SocketAddr and ip::IpAddr.

I guess it would also make sense for parser to be in addr::parser instead.

[thomcc]

I'm not sure this level of nesting helps?

[reitermarkus]

I'm not sure this level of nesting helps?

How do you suggest to structure this?

[thomcc]

How do you suggest to structure this?

I think what you had initially was probably better, but honestly I think just the changes so that DisplayBuffer is used for the parsing would be fine.

[bors]

☔ The latest upstream changes (presumably #100881) made this pull request unmergeable. Please resolve the merge conflicts.

[reitermarkus]

I flattened the module structure again, but did rename addr to socket_addr and ip to ip_addr so the names are more symmetric.

[thomcc]

Thank you. This looks great. Will approve after CI goes green.

[thomcc]

@bors r+

[bors]

📌 Commit d61ecec has been approved by thomcc

It is now in the queue for this repository.

[reitermarkus]

@rustbot ready

[thomcc]

@Jarcho is this what you were looking for?

[thomcc]

I'm fine with the library portion, so I'm going to reassign to @Jarcho for the review of the clippy changes, since I have no idea what I'm looking at there.

r? @Jarcho

[Jarcho]

Clippy changes look good.

[thomcc]

@bors r+

[bors]

📌 Commit 14230a7 has been approved by thomcc

It is now in the queue for this repository.

[bors]

⌛ Testing commit 14230a7 with merge c815756...

[bors]

☀️ Test successful - checks-actions
Approved by: thomcc
Pushing c815756 to master...

[rust-timer]

Finished benchmarking commit (c815756): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	2.5%	[2.5%, 2.5%]	1
Regressions ❌ (secondary)	1.6%	[0.5%, 2.5%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-2.6%, -2.6%]	1
All ❌✅ (primary)	2.5%	[2.5%, 2.5%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	2.8%	[2.8%, 2.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.7%	[-3.7%, -3.7%]	1
All ❌✅ (primary)	2.8%	[2.8%, 2.8%]	1

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²