Rollup of 4 pull requests

[matthiaskrgr]

Successful merges:

• Document textual format of SocketAddrV{4,6} #131790 (Document textual format of SocketAddrV{4,6})
• Stabilize shorter-tail-lifetimes #131983 (Stabilize shorter-tail-lifetimes)
• sanitizer.md: LeakSanitizer is not supported on aarch64 macOS #132097 (sanitizer.md: LeakSanitizer is not supported on aarch64 macOS)
• Remove visit_expr_post from ast Visitor #132107 (Remove visit_expr_post from ast Visitor)

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

[matthiaskrgr]

@bors r+ rollup=never p=4

[bors]

📌 Commit a8cea36 has been approved by matthiaskrgr

It is now in the queue for this repository.

[bors]

⌛ Testing commit a8cea36 with merge a93c171...

[bors]

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing a93c171 to master...

[rust-timer]

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#131790	Document textual format of SocketAddrV{4,6}	e08b0f8a05a136048a1ca2ea3ff577497b138bb6 (link)
#131983	Stabilize shorter-tail-lifetimes	5d30201178463079b2aa1a023791f2c8468d2702 (link)
#132097	sanitizer.md: LeakSanitizer is not supported on aarch64 mac…	e61e1e04d8f597bfe210cdafed5d8933f2d1c553 (link)
#132107	Remove visit_expr_post from ast Visitor	bdf1f6eacffbcbb48e6caa27d516c49317fe66f6 (link)

previous master: 1d4a7670d4

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

[rust-timer]

Finished benchmarking commit (a93c171): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 1.8%]	49
Regressions ❌ (secondary)	0.8%	[0.1%, 1.3%]	6
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.3%]	1
Improvements ✅ (secondary)	-0.7%	[-1.8%, -0.1%]	3
All ❌✅ (primary)	0.3%	[-0.3%, 1.8%]	50

Max RSS (memory usage)

Results (primary 1.0%, secondary 2.1%)

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.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.9%, 1.0%]	2
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.9%, 1.0%]	2

Cycles

Results (primary 1.5%, secondary -1.6%)

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.

	mean	range	count
Regressions ❌ (primary)	1.5%	[0.8%, 2.5%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	1.5%	[0.8%, 2.5%]	4

Binary size

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

Bootstrap: 785.158s -> 783.896s (-0.16%)
Artifact size: 333.66 MiB -> 333.71 MiB (0.01%)

[lqd]

@rust-timer build 5d30201

[rust-timer]

Finished benchmarking commit (5d30201): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 1.7%]	50
Regressions ❌ (secondary)	0.5%	[0.1%, 0.9%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.8%	[-2.1%, -0.1%]	3
All ❌✅ (primary)	0.3%	[0.1%, 1.7%]	50

Max RSS (memory usage)

Results (primary 2.9%, secondary 2.3%)

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.

	mean	range	count
Regressions ❌ (primary)	2.9%	[0.9%, 5.0%]	3
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.9%	[0.9%, 5.0%]	3

Cycles

Results (primary 2.5%, secondary -1.8%)

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.

	mean	range	count
Regressions ❌ (primary)	2.5%	[2.5%, 2.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	1
All ❌✅ (primary)	2.5%	[2.5%, 2.5%]	1

Binary size

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

Bootstrap: 785.158s -> 785.685s (0.07%)
Artifact size: 333.66 MiB -> 333.69 MiB (0.01%)

[lqd]

Ah so these are from #131983, were these regressions expected or is there maybe some way to reduce them @dingxiangfei2009 @lcnr?

[dingxiangfei2009]

@lqd

Ah so these are from #131983, were these regressions expected or is there maybe some way to reduce them @dingxiangfei2009 @lcnr?

Here is my theory. This change will lead to extra data generated for each instance of a tail expression of a block. Given that they are a common occurrence I expected some regression will happen. I won't just sign it off right away, though. I will investigate the pref report now. Thanks for the heads-up!

Also, feel free to pull me into any conversation to look at it together with others over Zulip!

[dingxiangfei2009]

By extra data, I mean we will generate

• extra ScopeData for each tail expression,
• extra thir::ExprKind::Scope entry for each tail expression

MIR size should stay roughly the same, however.

[Kobzol]

Visiting from weekly triage (thanks @lqd for the perf. run!). It looks like some queries are now being caled more often, e.g. is_copy_raw - could that have been the culprit?

Not marking as triaged yet.