rustdoc: Fix ICE when deprecated note is not resolved on the correct DefId

[GuillaumeGomez]

Supersedes #151237.
Follow-up of #151120.

The span overlapping approach wasn't good enough so instead we now check if the reexport itself has the deprecated attribute, and if so, we resolve the path to the reexport DefId, otherwise we resolve it on the reexported item's DefId.

cc @Zalathar
r? @lolbinarycat

[GuillaumeGomez]

And fixed fmt...

[lolbinarycat]

@bors r+

I don't see what would've caused an ICE in the last one except maybe the expect_def_id, in which case it's probably better to raise an error than use some fallback likely to cause improper resolution? This approach does look much more robust, though.

[rust-bors]

📌 Commit 1faaa76 has been approved by lolbinarycat

It is now in the queue for this repository.

[GuillaumeGomez]

@bors r+

I don't see what would've caused an ICE in the last one except maybe the expect_def_id, in which case it's probably better to raise an error than use some fallback likely to cause improper resolution? This approach does look much more robust, though.

The span of the item doesn't always contain the attribute (guess how I found out =D). So we tried to resolve the intra-doc link in the wrong scope, which ended very badly.

[Kobzol]

@bors p=10

Just in case the rollup currently being tested fails, as this causes errors in rustc-perf and blocks is CI.

[Zalathar]

Will this want a beta backport for 1.94?

The previous PR was merged before the 1.95 version bump, so I assume the new beta branch will still have the ICE.

[GuillaumeGomez]

Arf, missed the release. Nominating for backport then. Thanks for the ping!

[Zalathar]

Also note that the rollup had a bunch of doc perf regressions, though I imagine they're probably justified by the bugfix.

• Rollup of 8 pull requests #151395 (comment)