rustdoc: Box GenericArg::Const to reduce enum size

[camelid]

This should reduce the amount of memory allocated in the common cases
where the GenericArg is a lifetime or type.

[camelid]

(It's blocked because they change similar code and I think that could cause the results to be spurious.)

[hellow554]

#88522 has been merged successfully and no rebase seems to be needed. So let's go?

[camelid]

#88522 has been merged successfully and no rebase seems to be needed. So let's go?

Yeah, I forgot that CI rebases before testing, but I'll still rebase just in case :)

[camelid]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 3b61d37a27214aacc220e8eb6c37c176e8617832 with merge 459a20808114e18608987a33b457c76d3ffa7a17...

[camelid]

r? @GuillaumeGomez

[bors]

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

[rust-timer]

Queued 459a20808114e18608987a33b457c76d3ffa7a17 with parent fcce644, future comparison URL.

[rust-timer]

Finished benchmarking try commit (459a20808114e18608987a33b457c76d3ffa7a17): comparison url.

Summary: This change led to small relevant mixed results 🤷 in compiler performance.

• Small improvement in instruction counts (up to -0.4% on incr-full builds of deep-vector)
• Small regression in instruction counts (up to 0.5% on full builds of deep-vector)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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 fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

[camelid]

I'm pretty sure those regressions that rust-timer is reporting are spurious, because they are for non-doc builds, which shouldn't be affected at all by this change.

No significant changes in *-doc instruction count, but max-rss looks to be improved on virtually all *-doc benchmarks; the biggest improvements are for deeply-nested-doc at 1.2%, clap-rs-doc at about 1%, and serde-doc at about 1%. The only significant (according to the webpage) regression is 0.21% for tokio-webpush-simple-doc, which could be spurious.

[Mark-Simulacrum]

@bors try @rust-timer queue

Let's see if they reproduce, perhaps? But seem likely to not be related to this PR.

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 3b61d37a27214aacc220e8eb6c37c176e8617832 with merge d19374152c9e11c22593659de62dfacd47145920...

[bors]

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

[rust-timer]

Queued d19374152c9e11c22593659de62dfacd47145920 with parent b834c4c, future comparison URL.

[rust-timer]

Finished benchmarking try commit (d19374152c9e11c22593659de62dfacd47145920): comparison url.

Summary: This change led to small relevant mixed results 🤷 in compiler performance.

• Small improvement in instruction counts (up to -0.6% on full builds of deep-vector)
• Small regression in instruction counts (up to 0.5% on incr-full builds of coercions)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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 fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

[GuillaumeGomez]

Should we add a static_assert_size! for GenericArg then?

[camelid]

Seems pretty likely that these rustc regressions and rustc improvements are spurious, because they shouldn't be affected by this change and because in the first run, it reported

Small regression in instruction counts (up to 0.5% on full builds of deep-vector)

but on this run, it reported:

Small improvement in instruction counts (up to -0.6% on full builds of deep-vector)

Removing the perf-regression label then.

[camelid]

tuple-stress-doc showed a 10% max-rss regression in the second perf run, but I'm pretty sure it's spurious because there were no significant changes for it in the first run. Also, it doesn't use anything that I would expect to be affected by this change.

[camelid]

Aside from that, significant improvements ranged from 0.3% to 1%. serde-doc improved by the exact same amount both runs too (1.03%).

[camelid]

Should we add a static_assert_size! for GenericArg then?

Yeah, that's probably a good idea.

[camelid]

Should we add a static_assert_size! for GenericArg then?

Ok, done!

[GuillaumeGomez]

Thanks!

@bors: r+ rollup

[bors]

📌 Commit 5c0e6c1 has been approved by GuillaumeGomez

[camelid]

@bors rollup-

This affects performance.

[camelid]

@bors rollup=never

[bors]

⌛ Testing commit 5c0e6c1 with merge b89e01c...

[bors]

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing b89e01c to master...