Fix deprecated attribute intra-doc link not resolved in the right location on reexported item

[GuillaumeGomez]

Fixes #151028.
Follow-up of #150721.

So when we resolve an intra-doc link, its current context (the module from which we resolve in short) is very important. However, when we use an intra-doc link in a #[deprecated] attribute on a reexported item, we were using the context of the reexported item and not of the use itself. Meaning that if you have an intra-doc link std::mem::drop on an item from another crate (let's say core), then the import will simply fail since there is no std dependency.

Now comes the not so funny fix: at this point, we don't know anymore where the attribute came from (ie, from the reexport or from the reexported item) since we already merged the attribute at this point. The solution I found to go around this problem is to check if the item span contains the attribute, and if not, then we use the inline_stmt_id as context instead of the item's ID. I'm not super happy and I'm sure we'll find corner cases in the future (like with macros), however there are a few things that mitigate this fix:

1. The only way to generate an attribute with a macro with its item while having different spans is by using proc-macros. In that case, we can always default to the inline_stmt_id as context and be fine, but I guess we'll see when get there.
2. It only concerns reexports, so the area of the problem is quite restricted.

Hopefully this explanation made sense. :)

cc @folkertdev
r? @lolbinarycat

[GuillaumeGomez]

Rebased on main, hopefully it should pass.

[lolbinarycat]

Reviewing this now, I've verified that the new regression test does in fact crash current main, which is good.

[lolbinarycat]

Two small potential improvements, otherwise the code looks good!

View changes since this review

[lolbinarycat]

Suggested change

	let item_id = if let Some(inline_stmt_id) = item.inline_stmt_id
	&& !item.span(tcx).is_none_or(|item_span| item_span.inner().contains(*span))
	{
	inline_stmt_id.to_def_id()
	} else {
	item.item_id.expect_def_id()
	};
	insert_links(item_id, note)
	// when resolving an intra-doc link inside a deprecation note
	// that is on an inlined `use` statement, we need to use the `def_id` of
	// the `use` statement, not the inlined item.
	// <https://github.com/rust-lang/rust/pull/151120>
	let item_id = if let Some(inline_stmt_id) = item.inline_stmt_id
	&& item.span(tcx).is_some_and(|item_span| !item_span.inner().contains(*span))
	{
	inline_stmt_id.to_def_id()
	} else {
	item.item_id.expect_def_id()
	};
	insert_links(item_id, note)

1. I think moving the negation inwards makes the condition easier to reason about
2. This is a weird edge case so I think it's good to give a comment. yes git blame exists but if a refactor happens between now and when this needs to be re-investigated, it might not be very helpful (it doesn't have to be this exact comment, feel free to write your own if you think you can do better, i left out the macro hazard for brevity).

[GuillaumeGomez]

Agreed for the comment, however if the span is None, or doesn't contain the attribute, then we should use the use span, which means my original condition was wrong too, the ! should have been for the contains, not the whole thing. ^^'

[lolbinarycat]

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • c341745

[GuillaumeGomez]

Added comment and fixed condition.

[lolbinarycat]

The new condition has a different behavior than the old one, and from the equivalent one I suggested. was this intentional? why?

[GuillaumeGomez]

yes it's intentional, explained it in my comment. ;)

[gulfemsavrun]

Could we please expedite the review of this PR? Our toolchain builders have been blocked for a week due to the issue reported here: rust-lang/rust#151028. We would greatly appreciate your help in getting this landed.