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
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:
where
pavex_runtimeis a third-party dependency that does nothing more than a public re-export: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
innerhints at the fact that we depend onhttp::Requestthrough a re-export viapavex_runtime.If I follow the
id, I instead go directly to the canonical item definition inhttp:nameseems to be the only place whererustdocexposes the information that the dependency from my crate tohttpflows through a re-export inpavex_runtime.Further experiments seem to suggest that
nameis set to whatever is used as the type name alias in the function definition.E.g. by rewriting the definition as
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 onhttpthrough a re-export inpavex_runtime.What I expect to see
I'd expect the
extract_pathfunction item to refer, in its parameter list, to some kind of re-export item kind that is associated withpavex_runtimeinstead of going directly tohttp.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 (viapavex_runtime).Other relevant information
Latest nightly, format version
18.Related
zulip's discussion with @GuillaumeGomez