Search for type names in dependencies

[Dylan-DPC-zz]

From a Twitter discussion, quoting @GuillaumeGomez :

I think something feasible would be search between a crate and its dependencies. Merging the search-index files isn't very complicated (even with the minification!) but that'd require way too much space and computation. Something not too complicated would be to provide the dependencies search-index files when looking for "more".

Creating this issue so that we remember it in future and possibly implement it

(Context: Idea was suggested by @gilescope who wanted a functionality similar to Haskell's hoogle

[GuillaumeGomez]

It's already the case. You need to open it in docs.rs. ;)

[Dylan-DPC-zz]

@GuillaumeGomez I don't have permissions on that repo so you will have to move the issue there (by using transfer issue option )

[GuillaumeGomez]

Transferred.

[gilescope]

Hoogle is great, but I wonder if we can do better. Can we autogenerate maps that visualise the possible routes to get from one type to another. Here's a graphviz of getting to/from String,&str,OsString.OsStr,PathBuf,Path... (I've probably missed a few paths as it's not autogenerated), but it would be pretty epic to give a handful of types and for a graph to show me how I could get from one to the other.

digraph finite_state_machine {
	rankdir=LR;
	size="8,5"
        "&[u8]" -> String [label = "String::from_lossy()"]
        "&str" -> "&OsStr" [ label = "OsStr::new()"]
        "OsString" -> String [ label = "into_string()"]
        "&OsStr" -> OsString [ label = "to_os_string()" ]
        "&str" -> OsString [ label = "from()"]
	String -> "&str" [ label = "&" ];
        "&str" -> String [ label = "to_owned(), to_string()"]
        "&Path" -> String [ label = "to_string()"]
        "&Path" -> "&OsStr" [ label = "as_os_str()" ]
        PathBuf -> String [label = "to_string()"]
        PathBuf -> "&Path" [label = "&" ]
        PathBuf -> OsString [label = "into_os_string()"]
        "&OsStr" -> "&Path" [label = "Path::new()"]
       OsString -> "&OsStr" 
}

(You can paste the above into http://webgraphviz.com/ )

It might be worth distinguishing the owned types from the refernce types...

[gilescope]

@steveklabnik tweeted in https://t.co/b0WKl6Bmm1 that docs.rs supported vec -> usize though that doesn't seem to alas work any longer.

[jyn514]

@gilescope your idea sounds really cool but I'm not sure it belongs in this issue. Search terms are a special case - they're already generated by rustdoc for local docs, docs.rs just needs integrate them into the main site.

If you're interested in the graph idea, could you open an issue in https://github.com/rust-lang/rust for rustdoc?

[jyn514]

provide the dependencies search-index files when looking for "more".

@Dylan-DPC can you expand on this? I'd like to implement it but I'm not familiar with how search indexing works.

Do we know why cross-crate search isn't currently working on docs.rs? Is it because we pass --no-deps to cargo doc?

[jyn514]

Suggestions from discord:

• Only search in direct dependencies to avoid overwhelming the user on crates with lots of dependencies (anything over ~50 means that you get hundreds of results). These are easy to find through Cargo.toml.
• Add a 'more ... ' button so it only searches in the current crate by default (maybe 'even more ...' means all dependencies?)
• @GuillaumeGomez said merging the search index should be as easy as grabbing the second line of search_index.js for each dependency and then merging those into a single JS file. This could be done ahead of time to avoid having to download thousands of indexes each day.

[GuillaumeGomez]

The search-index.js file format has been very stable since the start of its existence but just in case: any changes to this file will need the docs.rs side to be aware of it if we decide to base our solution on it.

[jyn514]

@steveklabnik tweeted in https://t.co/b0WKl6Bmm1 that docs.rs supported vec -> usize though that doesn't seem to alas work any longer.

@gilescope That link is broken ... do you have a link for the tweet?

[steveklabnik]

That tweet is here: https://twitter.com/steveklabnik/status/727530114607661057

rustdoc already supports a VERY LIMITED form of this http://doc.rust-lang.org/std/?search=vec%20-%3E%20usize

[jnordwick]

any progress or updates? It is at the point that it takes me hours to read a few lines of cod because I spend mot of that time trying to find out what is even being called.

[GuillaumeGomez]

I opened rust-lang/rust#86715 about this. Nothing has been done for the moment.

[jnordwick]

Thanks. Not sure much will be done, but the language has become incredibly difficult to understand when you don't know where a function comes from. Some IDE features can help, but you aren't always using an IDE. The flip side to this is a way to see all function that can be called on a value. Beside the impls directly for it, there is also all the one syou don't even know about (eg, I had no idea read/write was on the FutureEx trait instead so wanted 2-3 hours trying to future it out then just started asking what I can run on it and was quickly overwhelmed by the amount of searching required. Something that couple terminus what was implemented for a value so you could explore in a more directed manor would help a lot. I think every language I've become good at I've learned that way to a large extent - but I find it very difficult in rust.

…

On Thu, Apr 14, 2022 at 8:15 AM Guillaume Gomez ***@***.***> wrote: I opened rust-lang/rust#86715 <rust-lang/rust#86715> about this. Nothing has been done for the moment. — Reply to this email directly, view it on GitHub <#494 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASBHXDTDLK7X7XP4UFCESDVFAK6JANCNFSM4JSF3WBQ> . You are receiving this because you commented.Message ID: <rust-lang/docs. ***@***.***>