rustdoc: Store intra-doc links in Cache instead of on items directly

[jyn514]

Items are first built after rustdoc creates the TyCtxt. To allow
resolving the links before the TyCtxt is built, the links can't be
stored on clean::Item directly.

Helps with #83761. Opening this early because I think it might decrease memory usage.

[rust-highfive]

Some changes occurred in intra-doc-links.

cc @jyn514

[rust-highfive]

r? @GuillaumeGomez

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

[jyn514]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit e7e384048d837ecba22235e884aeaca5a32668b1 with merge 687f724d5dd477b34197157d39c27f0d608a032c...

[bors]

💔 Test failed - checks-actions

[jyn514]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 6beac7ada1af649615cafd2f2a83bff81a20b718 with merge 96bcaeeb0e14a08764e7c4fe479898bfee094c27...

[bors]

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

[rust-timer]

Queued 96bcaeeb0e14a08764e7c4fe479898bfee094c27 with parent 2616ab1, future comparison URL.

[rust-timer]

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

[GuillaumeGomez]

Interesting, the performance are reduced a bit (max +0.9%). However, we have a nice improvement on the memory usage (max -1.9%).

[GuillaumeGomez]

Looks good to me. Maybe @camelid wants to review again?

[jyn514]

Oh, I forgot to try using ThinVec. Let me do that real quick.

[jyn514]

Oh, I forgot to try using ThinVec. Let me do that real quick.

This currently breaks because it needs the changes from #83821. @camelid do you want me to wait for those to compare the performance? Note that the results will be slightly inaccurate because they'll be comparing different base commits.

[GuillaumeGomez]

Well, you can always add a FIXME to give it a try until then if it's not merged before @camelid comes around.

[jyn514]

@bors r=GuillaumeGomez

[bors]

📌 Commit 5667879d51b061f690340316a5f48c4e1e668402 has been approved by GuillaumeGomez

[camelid]

Oh, I forgot to try using ThinVec. Let me do that real quick.

This currently breaks because it needs the changes from #83821. @camelid do you want me to wait for those to compare the performance? Note that the results will be slightly inaccurate because they'll be comparing different base commits.

I'm not sure if using ThinVec would actually improve performance. I think BTreeMap already stores values behind a pointer. Based on a quick test in the Playground, ThinVec does not change the size of Cache.intra_doc_links. But maybe it would still make a difference in some other way?

[bors]

☔ The latest upstream changes (presumably #83905) made this pull request unmergeable. Please resolve the merge conflicts.

[jyn514]

Hmm, I just realized ThinVec won't help much anyway because the vec will never be empty, the intra doc pass only creates it if it's going to add a link.

[jyn514]

@bors r=GuillaumeGomez rollup=never

[bors]

📌 Commit 9e11902 has been approved by GuillaumeGomez

[bors]

⌛ Testing commit 9e11902 with merge 1c158b6...

[bors]

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