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

c2bda49
Opened by Manish Goregaokar at 2022-03-05 23:57:59

Consider the following MWE:


pub trait Foo { fn root(); }

impl Foo for Option<uint>{
    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 type<sup>1</sup>? . 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.

<sup>1.</sup> 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.

  1. 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 type<sup>1</sup>? . 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.

    <sup>1.</sup> 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.

    León Orell Valerian Liehr at 2024-11-05 21:18:26

  2. s/uint/i32, but otherwise, no change.

    Steve Klabnik at 2015-11-07 07:12:03

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

    Oliver Middleton at 2016-07-12 12:23:06

  4. Triage: not aware of any changes here

    Steve Klabnik at 2019-03-11 17:25:00

  5. 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?

    Noah Lev at 2022-01-09 02:16:03

  6. 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.

    Andrius Pukšta at 2022-03-05 13:37:09

  7. 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?

    Noah Lev at 2022-03-05 23:57:59