Tracking issue for providing a mechanism for resolving type-relative HIR paths in item signatures to their definition outside of HIR ty lowering

[fmease]

Background

For type-dependent HIR paths (TypeRelative QPaths and MethodCalls) in bodies, we persist a mapping from HirId to Result<DefId, _> in TypeckResults.type_dependent_defs via query typeck_root that finds great use in HIR-based compiler & tool passes (e.g., dead code analysis, lints, rustdoc, Clippy).

However, there is no such mapping for type-dependent HIR paths in item signatures (non-bodies). That's quite unfortunate since it basically prevents us from properly implementing certain features like linting unused associated types (cc comments in PR #148654, issues #127673 and #110332) and rustdoc's link-to-definition for associated types in item signatures.

The only workarounds we might have is to

1. re-HIR-ty-lower the relevant HIR path in the necessary places which is costly, possibly ICE-y and generally janky.
2. call type_of or similar and somehow try to find the path in the middle::ty IR; that's impossible to do correctly esp. since type aliases currently aren't represented in that IR (not until LTA_unchecked is unconditionally enabled)
3. switch to middle::ty IR for the analysis either partially (by keeping the HIR approach for all other HIR nodes; possibly costly, hard to maintain) or fully (if that's possible, good job!)

So ideally we had a typeck_root+TypeckResults.type_dependent_defs equivalent for item signatures / non-bodies. While FnCtxts (used for bodies) can write back such resolutions, ItemCtxts (used for non-bodies) cannot.

It's still unclear to me how the design for "item signature write-back" should / would look like. The vague idea would be to make each ItemCtxt store a new BikeshedTypeDepDefs that's either

• written back at "common public entry points" of HIR ty lowering using query feeding (query key is the LocalDefId of the item) or
• persisted by turning some "common public entry points" of HIR ty lowering into queries that return something akin to (Ty, BikeshedTypeDepDefs)

During HIR ty lowering, resolutions would be recorded via <ItemCtxt as HirTyLowerer>::record_ty or a new bikeshed_write_res.

Ideally we would somehow consolidate the handling of "type-dependent defs" in bodies & non-bodies (might not be worth it) or at least provide an interface that handles body (TypeckResults.type_dependent_defs) vs. item signature (BikeshedTypeDepDefs) transparently, so other parts of the compiler / tools don't need to think about it (e.g., we want a unified qpath_res and a unified type_dependent_def_id).

[fmease]

(The naive idea I had years ago was to just intro a feedable query item_sig_type_dep_def_id(key: HirId) -> Result<DefId> that's fed directly in ItemCtxts during HIR lowering (so no BikeshedTypeDepDefs in ItemCtxts); however I was informed that that would most likely be unsound wrt. incremental compilation given the fact that a HirId is used as a query key)

[mu001999]

• persisted by turning some "common public entry points" of HIR ty lowering into queries that return something akin to (Ty, BikeshedTypeDepDefs)

For the record, I plan to try this approach first. I think it is more explicit, and easier to implement incrementally.