Generated documentation should display implicit trait implementations

[frewsxcv]

use std::fmt;

struct A;

impl fmt::Display for A {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "A")
    }
}

In this example, I'm able to call let a = A; a.to_string() since A implements fmt::Display. The generated documentation doesn't mention anything about to_string. It'd be great if the documentation displayed all available methods for a given structure.

[frewsxcv]

FYI, this implementation exists in case people were confused about the description above:

impl<T> ToString for T where T: Display + ?Sized

https://doc.rust-lang.org/std/string/trait.ToString.html

[GuillaumeGomez]

I'll take a look.

[GuillaumeGomez]

I've been looking for a few days and here are my current issues:

• I don't know how I can get information on trait impls in sub crates.
• I don't know how I can resolve the genericity "issue" (being able to know if a trait impl is also done on the type I'm looking for).

[cbreeden]

I have been working through the source code for method resolution (ie: how rustc resolves A.to_string() in this example) while working on reference documentation for the "dot" operator. See 36427.

I am under the impression that most of the logic found in the source for method resolution can translate to listing out implicit trait implementations. I'll take a look after I'm finsihed with the documentation, but if anyone else is curious to give it a stab, take a look at reference links found in 36427.

[frewsxcv]

Awesome, thanks for sharing @cbreeden! I've been wanting to look into this issue, but I'm still reading through the librustdoc module. I haven't (yet) made any progress on this issue. Will update here if I do.

[HybridEidolon]

How would this information be shown for generic types? i.e. Thing<B> and impl<T: Debug> Debug for Thing<T> {} -- a separate section saying something like "When B is Debug..."?

[frewsxcv]

@HybridEidolon Is there any reason you can think of why the shouldn't go in the already existing "Trait Implementations" section?

[GuillaumeGomez]

@HybridEidolon: For the moment, "everyone" wants it. If your issue is just for the output wording, we can always resolve the type name before printing.

[GuillaumeGomez]

I'll give a serious look into this to settle this matter once and for all.

[coder543]

This came up again today, just FYI.

From what I've heard, RLS has the potential to help a lot with generating documentation. Is this being actively worked on, or is it blocked on that?

[steveklabnik]

Is this being actively worked on, or is it blocked on that?

Existing rustdoc is not being actively worked on. Well, @GuillaumeGomez is doing some things, but we're generally not tackling this kind of bug right now. The idea is that the new rustdoc will be fixing this kind of thing.

[theduke]

@steveklabnik first time I've heard about a new rustdoc.

Is there a discussion or tracking issue somewhere to read up on it? ( a quick search didn't help me find anything).

[coder543]

@theduke I've heard rumors floating around for awhile now that the new rustdoc will simply ask RLS for the documentation on each item in each crate, and maybe query RLS for some other things. This is because RLS will already know everything about all of the code, including docstrings, which traits a given type implements, etc.

[ehsanul]

https://github.com/steveklabnik/doxidize

Edit: nvm, apparently that's a far future project.

The idea is that the new rustdoc will be fixing this kind of thing.

@steveklabnik This is no longer true, correct?

[GuillaumeGomez]

PR to fix it is now open.