Rollup of 5 pull requests

[matthiaskrgr]

Successful merges:

• Restrict #[rustc_box] to Box::new calls #108516 (Restrict #[rustc_box] to Box::new calls)
• Erase **all** regions when probing for associated types on ambiguity in astconv #108575 (Erase all regions when probing for associated types on ambiguity in astconv)
• Run compiler test suite in parallel on Fuchsia #108585 (Run compiler test suite in parallel on Fuchsia)
• Add test case for mismatched open/close delims #108606 (Add test case for mismatched open/close delims)
• Highlight whole expression for E0599 #108609 (Highlight whole expression for E0599)

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

[matthiaskrgr]

@bors r+ rollup=never p=5

[bors]

📌 Commit 832987b has been approved by matthiaskrgr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 832987b with merge 4912485f15667799e847fd3ae601e2e3d6837b50...

[bors]

💥 Test timed out

[matthiaskrgr]

@bors retry

[bors]

⌛ Testing commit 832987b with merge 7e966bc...

[bors]

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

[rust-timer]

📌 Perf builds for each rolled up PR:

PR#	Perf Build Sha
#108609	7a4b1a20b900dfffaca19ba6ef85c73965cab5b0
#108606	9ab93fea0a96e573a837990b60e655ea7c4ee216
#108585	0638a6d5124ae688ac3e35f4f54eeead662f777b
#108575	920d37d09964cf017aa3a0ccb49d4e3dd34e134b
#108516	e1c2a35058d45644d8ad0f3a09dd85cfe382c15e

previous master: 18caf88956

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 (7e966bc): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.2%	[2.1%, 4.4%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.5%, -2.6%]	2
All ❌✅ (primary)	-	-	0

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.7%	[2.3%, 6.2%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

[lqd]

#108575 is supposed to be on the error path and shouldn't be the cause here, but the regressions do contain more query traffic for associated_items, and it seems to be one of the few related things in this rollup.

So let's see just in case:
@rust-timer build 920d37d09964cf017aa3a0ccb49d4e3dd34e134b

[rust-timer]

Finished benchmarking commit (920d37d09964cf017aa3a0ccb49d4e3dd34e134b): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -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.

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

Cycles

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

[lqd]

@rustbot label: +perf-regression

[rust-timer]

Finished benchmarking commit (920d37d09964cf017aa3a0ccb49d4e3dd34e134b): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -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.

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

Cycles

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

[lqd]

Come on, bot.

@rustbot label: +perf-regression

[nnethercote]

Oh dear: I suspect deep-vector has succumbed to a similar problem as keccak and cranelift-codegen, i.e. bimodal codegen of process_obligations.

I was just doing some Cachegrind profiling of deep-vector, and noticed that process_obligations was the hottest function, which was not the case last week. I did a cg_diff, the changes are all in and around process_obligations. For me the difference with a check-full build is only 2%, not 4%, but I think this is the explanation :(

[rylev]

@nnethercote checking for triage: is there anything we should do to try to address this or do we just take this as another test case we should expect to see occasional perf swings in?

[nnethercote]

keccak and cranelift-codegen are always bimodal in sync. This deep-vector regression involves the same code but appears to be a once-off. I won't pretend to understand why it's behaving differently. But I am confident it's a question of code generation quality rather than, say, some change in the compiler that caused it to call the relevant functions more times. (I can tell this because in the Cachegrind profiles a lot of the lines in the relevant functions have the same number of instruction counts, but then others have higher instruction counts.)

[rylev]

I think that's enough justification to call this triaged. While we don't have a good explanation, there's no real point in trying to find code changes in this rollup that are to blame.

@rustbot label +perf-regression-triaged