Iterate on crate_inherent_impls for metadata.

[cjgillot]

Split from #80347

r? @oli-obk

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit ab17829 with merge f385c2df516c51b489279617f62ac9e6d3247628...

[bors]

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

[rust-timer]

Queued f385c2df516c51b489279617f62ac9e6d3247628 with parent 178bd91, future comparison URL.

[rust-timer]

Finished benchmarking try commit (f385c2df516c51b489279617f62ac9e6d3247628): 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

[oli-obk]

Huh... this regresses rustdoc? Idk how rustdoc handles metadata, but that seems very odd. Should we ping the rustdoc team?

[cjgillot]

TBH, all the differences are <1%, so I barely looked at them.

[oli-obk]

Yea... I'm fine regressing rustdoc a bit, but it would still be nice to track it, since it seems like a symptom of a deeper thing (I don't think this PR should affect rustdoc, and the fact that it does speaks for rustdoc doing something odd)

@bors r+

[bors]

📌 Commit ab17829 has been approved by oli-obk

[bors]

⌛ Testing commit ab17829 with merge 9320b12...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 9320b12 to master...