Rollup merge of #97613 - jsha:implementation-is-on-local-type, r=GuillaumeGomez

rustdoc: Improve calculation of "Impls on Foreign Types"

The existing code to calculate whether an implementation was on a "Foreign Type" was duplicated across the sidebar generation and the page generation. It also came to the wrong conclusion for some cases where both the trait and the "for" type were re-exports.

This PR extracts the logic into a method of `Impl`, breaks it into a multi-line method so it can be commented, and adds a case for when the trait and the "for" type came from the same crate. This fixes some cases - like the platform-specific integer types (`__m256`, `__m128`, etc). But it doesn't fix all cases. See the screenshots below.

[Before](https://doc.rust-lang.org/nightly/std/clone/trait.Clone.html#foreign-impls):

<img src="https://user-images.githubusercontent.com/220205/171338226-59ce6daf-3d76-4bad-bc8d-72a8259a8f43.png" width=200>

[After](https://rustdoc.crud.net/jsha/implementation-is-on-local-type/std/clone/trait.Clone.html):

<img src="https://user-images.githubusercontent.com/220205/171338147-28308a65-1597-4223-be47-9550062404dd.png" width=200>

The remaining types (`CString`, `NulError`, etc) are all from the `alloc` crate, while the `Clone` trait is from the `core` crate. Since `CString` and `Clone` are both re-exported by `std`, they are logically local to each other, but I couldn't figure out a good way to detect that in this code. I figure this is still a good step forward.

Related: #97610

r? `@camelid`

0 files changed, 0 insertions, 0 deletions