-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
rustdoc's treatment of cross-crate ("imported") files is suboptimal. #70757
Copy link
Copy link
Open
Labels
A-cross-crate-reexportsArea: Documentation that has been re-exported from a different crateArea: Documentation that has been re-exported from a different crateC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-cross-crate-reexportsArea: Documentation that has been re-exported from a different crateArea: Documentation that has been re-exported from a different crateC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
@bjorn3 noted in #70025 (comment) that single files missing disables
[src]links for the entire crate.That's not ideal UX, we should render as many source files as we can possible load.
And there's also the paths
rustdocuses (see #70025 (comment)), e.g.:If we use the
CrateNumof the original source file and reuse the existingrustdoclogic to get the relative path of that file in that crate, I believe we can even support linking to the source correctly even when the absolute paths are not usable (e.g./rustc/$hash/src/libstd/thread/local.rswhen usingthread_local!and therust-srcrustupcomponent isn't installed)Because the downstream crate uses an exported macro from the original crate, the rendered source file should always have been generated, so we should never really need to re-generate it.
cc @rust-lang/rustdoc @Aaron1011