Use DepKind instead of &'static str in QueryStackFrame

[ghost]

@rustbot author

Fixes #105168

[rustbot]

r? @nagisa

(rustbot has picked a reviewer for you, use r? to override)

[ghost]

r? @Nilstrieb

[ghost]

(GitHub... 💢)

[ghost]

@rustbot review

[jyn514]

r=me unless you want another review from nils :)

@bors delegate=gimbles rollup=never (perf sensitive)

[bors]

✌️ @gimbles can now approve this pull request

[Noratrieb]

Looks mostly good, a few small improvements, r=me with them (or r=jyn514, i leave that to you).

One other thing that could be changed is to use K instead of D for the generic because that's we use already but this would conflict with a "key" generic in one place so it's fine if you leave it like this imo, I (or you if you want) can change it as a follow-up.

[ghost]

@bors r+

[bors]

📌 Commit f8b3008 has been approved by gimbles

It is now in the queue for this repository.

[Noratrieb]

@bors r=Nilstrieb

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Take revision into account in non-incremental-mode // incremental tests #106053

[bors]

📌 Commit f8b3008 has been approved by Nilstrieb

It is now in the queue for this repository.

[bors]

⌛ Testing commit f8b3008 with merge c2ff8ad...

[bors]

☀️ Test successful - checks-actions
Approved by: Nilstrieb
Pushing c2ff8ad to master...

[rust-timer]

Finished benchmarking commit (c2ff8ad): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.2%	[0.2%, 0.2%]	4
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	2
Improvements ✅ (secondary)	-0.5%	[-0.7%, -0.3%]	5
All ❌✅ (primary)	0.1%	[-0.2%, 0.2%]	6

Max RSS (memory usage)

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

Cycles

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

[Noratrieb]

Filtering out rustc_query_system::query::plumbing::get_query from the cachegrind diff (which shows up with the same + and - because of the added generic param) it's pretty noisy, probably because of slighly different inlining decisions. Most changes are in encoding/decoding.

One interesting case is that DepNode::construct::<_, DefId> got slower and I can't find where the extra instructions could be coming from, as all related functions don't show up in the diff.

[pnkfelix]

• The primary effects here are to various incremental scenarios, by relatively small amounts in either direction.
• The PR reviewer already has posted some notes summarizing their investigation into the performance delta.
• This PR is adding a type parameter to several methods that did not have one before, which I expect to change code layout of the compiler itself.
• i.e. I would expect this kind of change to have broad but shallow effects on rustc performance, which is consistent with the timer report.
• Marking as triaged.

@rustbot label: +perf-regression-triaged