proof tree nits

[lcnr]

r? @BoxyUwU

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[BoxyUwU]

@bors rollup=never p=1 (likely to conflict)
r=me if using the flag on the example in rust-lang/trait-system-refactor-initiative#25 gives the same results as it did in #112351

[lcnr]

@bors r=BoxyUwU

test is the same modulo changes to DefId paths 😁

[bors]

📌 Commit e4b171a has been approved by BoxyUwU

It is now in the queue for this repository.

[compiler-errors]

@bors rollup- im gonna try this in a rollup

[klensy]

rust/compiler/rustc_middle/src/traits/solve/inspect.rs

Lines 68 to 74 in 1b6d4cd

	#[derive(Eq, PartialEq, Debug, Hash, HashStable)]
	pub enum CandidateKind<'tcx> {
	/// Probe entered when normalizing the self ty during candidate assembly
	NormalizedSelfTyAssembly,
	/// A normal candidate for proving a goal
	Candidate { name: String, result: QueryResult<'tcx> },
	}

Noticed while looking pr diff: currently name always static string, but allocated as String everywhere, maybe change it to str?

[bors]

⌛ Testing commit e4b171a with merge 4651421...

[lcnr]

Noticed while looking pr diff: currently name always static string, but allocated as String everywhere, maybe change it to str?

yeah, or well, the goal is to replace it with an enum (and add fn probe_candidate which takes a CandidateKind directly).

[bors]

☀️ Test successful - checks-actions
Approved by: BoxyUwU
Pushing 4651421 to master...

[rust-timer]

Finished benchmarking commit (4651421): 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.7%	[0.3%, 0.9%]	7
Regressions ❌ (secondary)	1.2%	[0.5%, 1.7%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.3%, 0.9%]	7

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)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-1.7%	[-3.6%, -0.6%]	10
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.7%	[-3.6%, -0.6%]	10

Cycles

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

Binary size

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

Bootstrap: 657.004s -> 657.077s (0.01%)

[BoxyUwU]

this doesn't even touch any code run by benchmarks its entirely new solver

[lqd]

Yeah it could just be the inlining noise happening even by simply looking at the old trait solver in a way it doesn't like. Similar to how #112351 also improved these same benchmarks unexpectedly (and this could be them returning to their steady state, which I feel is likely here).

I myself don't know what is old or new solver from the diff, or what is shared between the two, so maybe the weekly triage will see something we don't -- but most likely they can just mark this as triaged from your comment.

---

update: it does look like returning to previous values.