You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
rustdoc has a lot of issues handling type aliases, and I think a large part of that is due to the fact that once the cleaned ast is constructed, type aliases are essentially opaque, and code cannot see what type they point to.
clean::TypeAlias does exist, but there's no way to get that from a Path item, which is what shows up in type args.
lolbinarycat
added
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
and removed
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
labels
Mar 17, 2025
hold onto the TyCtxt for type alias resolution (kinda breaks the current model of rustdoc where rendering only depends on the cleaned AST)
collect a map of all type aliases by hooking rustdoc::clean::inline::build_type_alias (simple, but may have significant memory overhead)
collect a map of only the type aliases that are needed for rendering (eg. only type aliases that appear in the generic parameters of a deref Target type) (less memory usage, but significantly more complicated, and likely uses more cpu cycles)
rustdoc has a lot of issues handling type aliases, and I think a large part of that is due to the fact that once the cleaned ast is constructed, type aliases are essentially opaque, and code cannot see what type they point to.
clean::TypeAlias
does exist, but there's no way to get that from aPath
item, which is what shows up in type args.I encountered this when working on #138574
The text was updated successfully, but these errors were encountered: