ast: Remove some indirection layers from values in key-value attributes

[petrochenkov]

Trying to address some perf regressions from #78837 (comment).

[rust-highfive]

r? @matthewjasper

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

[petrochenkov]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

[bors]

⌛ Trying commit 4e34c7d7e884f56e81d2f73b969a4eafbbbd0355 with merge 702d7ce67a06c676371e5a9417e2172e3e0540f6...

[petrochenkov]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

[bors]

⌛ Trying commit d29c28eee068bb08e02782975524e0de57defe7d with merge e3c34b4b68e99fdff4c3f40e35e9df57d62b0085...

[bors]

☀️ Try build successful - checks-actions
Build commit: e3c34b4b68e99fdff4c3f40e35e9df57d62b0085 (e3c34b4b68e99fdff4c3f40e35e9df57d62b0085)

[rust-timer]

Queued e3c34b4b68e99fdff4c3f40e35e9df57d62b0085 with parent 76aca66, future comparison URL.

@rustbot label: +S-waiting-on-perf

[rust-timer]

Finished benchmarking try commit (e3c34b4b68e99fdff4c3f40e35e9df57d62b0085): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[petrochenkov]

r? @Aaron1011

[Aaron1011]

@petrochenkov: Can you rebase against master?

[petrochenkov]

Rebased.

[Aaron1011]

r=me with the two comments addressed.

[petrochenkov]

@bors r=Aaron1011

[bors]

📌 Commit 71cd6f4 has been approved by Aaron1011

[bors]

⌛ Testing commit 71cd6f4 with merge f30733a...

[bors]

☀️ Test successful - checks-actions
Approved by: Aaron1011
Pushing f30733a to master...

[rylev]

@petrochenkov@Aaron1011 It seems that this change caused some perf regressions. Given that the perf run you ran above yielded only positive results, this is likely due to some other change getting in before this landed that introduced perf gains which this PR subsequently reversed.

It looks like the largest perf hit was to the expand_crate query.

Additionally, it's not clear to me how this change helped addressed the original perf regression as the impacted benchmarks were not improved by this PR. Would you mind clarifying that?

[petrochenkov]

I'm ok with reverting this PR if it causes mixed results, I wouldn't say it brings any improvements besides the perf effect.

Additionally, it's not clear to me how this change helped addressed the original perf regression as the impacted benchmarks were not improved by this PR. Would you mind clarifying that?

#78837 introduced more indirection by boxing literals as interpolated expressions, this PR removed some indirection by keeping a single token instead of a Vec of tokens.
So these two indirection are located in different places, and may affect different tests differently, but I still hoped for them to counter-balance each other on average.

The ultimate solution to the regressions from #78837 is to keep AST on arena (like it's already done with HIR), so that no expressions are ever boxed. That would help not only expressions in key-value attributes, but all expressions in functions as well (which are in majority).