Clean up handling of `WrongNamespace` in `collect_intra_doc_links`

[jyn514]

Rustdoc looks in different namespaces for diagnostics: https://github.com/rust-lang/rust/blob/66a9cfadf89439ad3ea1b67b996c0a90ca4763bf/src/librustdoc/passes/collect_intra_doc_links.rs#L1569-L1572
So this is handled properly:

warning: unresolved link to `file::into_iter`
 --> tmp.rs:1:6
  |
1 | /// [type@file::into_iter]
  |      ^^^^^^^^^^^^^^^^^^^^ `file` is a macro, not a module or type, and cannot have associated items

However (after #76955), resolution_failure only looks at other namespaces if there are multiple path segments. So https://github.com/rust-lang/rust/blob/66a9cfadf89439ad3ea1b67b996c0a90ca4763bf/src/librustdoc/passes/collect_intra_doc_links.rs#L1114 and https://github.com/rust-lang/rust/blob/66a9cfadf89439ad3ea1b67b996c0a90ca4763bf/src/librustdoc/passes/collect_intra_doc_links.rs#L1242-L1244 are still necessary, because they handle cases like value@file and type@file.

It would be nice to clean this up so that WrongNamespace is only handled in one place, in resolution_failure.

Originally posted by @jyn514 in #76955 (comment)

[max-heller]

Attempting to disambiguate associated types/values of primitives with an incompatible disambiguator gives a confusing error:

error: unresolved link to `str::trim`
   |
 3 | //! [struct@str::trim]
   |      ^^^^^^^^^^^^^^^^
   |      |
   |      this link resolves to the associated function `trim`, which is not in the type namespace
   |      help: to link to the associated function, add parentheses: `str::trim()`

The error stems from a ResolutionFailure::WrongNamespace.

Originally posted in #80660 (comment)

Edit: I'd expect an "incompatible link kind" error

[jacobmealey]

@jyn514 I see this ticket is a couple of years old, are you still willing to mentor it / is the work still relevant?

[jyn514]

I'm willing to mentor, but I honestly don't know if it's still relevant. The first step would be to find where the code is today and see if it still has the original issue I posted.

[RodBurman]

A further two and half years have passed with apparently no progress or sample code to reproduce the issue, is it still "live" or has it quietly gone away with the changes to the compiler & toolchain?