Hi!
I have been playing around with rustdoc's JSON output for the past few weeks and I have now stumbled on a road block that I can't easily sort out on my own.

The problem

I have a function signature that looks like this:

pub fn extract_path(
    _inner: pavex_runtime::http::Request<pavex_runtime::hyper::body::Body>,
) -> PathBuf {
    todo!()
}

where pavex_runtime is a third-party dependency that does nothing more than a public re-export:

//! pavex_runtime/src/lib.rs
pub use hyper;
pub use http;

If I look at that function in the JSON output for the relevant crate, I see this item (stripping out irrelevant fields):

{
      "id": "0:18:1598",
      "crate_id": 0,
      "name": "extract_path",
      "kind": "function",
      "inner": {
        "decl": {
          "inputs": [
            [
              "_inner",
              {
                "kind": "resolved_path",
                "inner": {
                  "name": "pavex_runtime::http::Request",
                  "id": "31:1361:1602",
                  }
                }
              }
            ]
          ],
      }

The name in inner hints at the fact that we depend on http::Request through a re-export via pavex_runtime.
If I follow the id, I instead go directly to the canonical item definition in http:

    "31:1361:1602": {
      "crate_id": 31,
      "path": [
        "http",
        "request",
        "Request"
      ],
      "kind": "struct"
    },

name seems to be the only place where rustdoc exposes the information that the dependency from my crate to http flows through a re-export in pavex_runtime.
Further experiments seem to suggest that name is set to whatever is used as the type name alias in the function definition.
E.g. by rewriting the definition as

use pavex_runtime::http::Request;

pub fn extract_path(
    _inner: Request<pavex_runtime::hyper::body::Body>,
) -> PathBuf {
    todo!()
}

the name now shows up as Request.
This would imply that there is no way to reliably detect that extract_path (and the crate where it is defined) depend on http through a re-export in pavex_runtime.

What I expect to see

I'd expect the extract_path function item to refer, in its parameter list, to some kind of re-export item kind that is associated with pavex_runtime instead of going directly to http.
E.g. an item of kind "import".

This would allow consumers of the JSON representation to navigate up to the source type (http::Request) while retaining the information that the current crate does not depend on it directly (via pavex_runtime).

Other relevant information

Latest nightly, format version 18.

Related zulip's discussion with @GuillaumeGomez