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.