Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Ghost" methods in rustdoc for cross-crate trait impls #18717

Open
Manishearth opened this issue Nov 6, 2014 · 6 comments
Open

"Ghost" methods in rustdoc for cross-crate trait impls #18717

Manishearth opened this issue Nov 6, 2014 · 6 comments
Labels
C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@Manishearth
Copy link
Member

Manishearth commented Nov 6, 2014

Consider the following MWE:

pub trait Foo { fn root(); }

impl Foo for Option<usize> {
    fn root() {}
}

Compiling, and navigating to doc/lib/index.html?search=root shows a clickable core::option::Option::root result. Clicking on it takes you to doc/core/option/enum.Option.html#method.root -- the page doesn't exist, however if you've copied in the docs like Servo does, you'll get the following search page and result — the actual trait is here.

Since crates are compiled by rustdoc individually, a cross-crate trait implementation can't show up on the type it is implemented on. However, it still is part of the search results, which is confusing. Removing it from search results isn't an option either — there still is the problem that a doc comment for methods in this impl will not be shown anywhere.

Perhaps cross crate trait implementations should go in the crate of origin of the impl, not the type1? . This will make search results work.

We'd need a new type of doc page for this though -- one that displays a single trait implementation; or alternatively all the trait impls for a type defined outside of a crate. Some sort of "addendum" page.

1. Crate of origin of trait doesn't work either since we can have trait A<T> from crate a, type B from crate b, and type C from crate c, with an impl A<C> for B in crate c, which we encounter while compiling crate c and can no longer touch the docs for crate a, which is the crate of origin of the trait.

@jdm jdm added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Nov 7, 2014
@steveklabnik

This comment has been minimized.

@ollie27
Copy link
Member

ollie27 commented Jul 12, 2016

#34752 removes the erroneous search results but doesn't fix the bigger issue.

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 22, 2017
@steveklabnik
Copy link
Member

Triage: not aware of any changes here

@camelid
Copy link
Member

camelid commented Jan 9, 2022

Since crates are compiled by rustdoc individually, a cross-crate trait implementation can't show up on the type it is implemented on.

These days, rustdoc inserts cross-crate trait impls using JS, so I think this issue should be fixed now? Should we close it?

@ehuss ehuss removed the T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. label Jan 18, 2022
@yjhn
Copy link
Contributor

yjhn commented Mar 5, 2022

When traits have a blanket impl for T (T may be restricted by trait bounds), trait impl docs don't show up anywhere. Example: compare Crossterm docs with actual source.

Related: #92641.

@camelid
Copy link
Member

camelid commented Mar 5, 2022

I think that is a different issue. I believe it may be intentional that blanket impls do not have their docs repeated, but I'm not sure. @jsha do you know anything about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants