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

Search for type names in dependencies #494

Open
Dylan-DPC-zz opened this issue Nov 26, 2019 · 14 comments
Open

Search for type names in dependencies #494

Dylan-DPC-zz opened this issue Nov 26, 2019 · 14 comments
Labels
A-frontend Area: Web frontend E-medium Effort: This requires a fair amount of work P-medium Medium priority S-needs-design Status: There's a problem here, but no obvious solution; or the solution raises other questions

Comments

@Dylan-DPC-zz
Copy link

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
Copy link
Member

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

@Dylan-DPC-zz
Copy link
Author

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

@GuillaumeGomez GuillaumeGomez transferred this issue from rust-lang/rust Nov 27, 2019
@GuillaumeGomez
Copy link
Member

Transferred.

@gilescope
Copy link

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
Copy link

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

@jyn514
Copy link
Member

jyn514 commented Dec 2, 2019

@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
Copy link
Member

jyn514 commented Dec 7, 2019

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
Copy link
Member

jyn514 commented May 27, 2020

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
Copy link
Member

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 jyn514 added A-frontend Area: Web frontend E-hard Effort: This will require a lot of work P-medium Medium priority S-needs-design Status: There's a problem here, but no obvious solution; or the solution raises other questions E-medium Effort: This requires a fair amount of work and removed E-hard Effort: This will require a lot of work labels Jul 6, 2020
@jyn514
Copy link
Member

jyn514 commented Jul 25, 2020

@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
Copy link
Member

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
Copy link

jnordwick commented Apr 14, 2022

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
Copy link
Member

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

@jnordwick
Copy link

jnordwick commented Apr 27, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Web frontend E-medium Effort: This requires a fair amount of work P-medium Medium priority S-needs-design Status: There's a problem here, but no obvious solution; or the solution raises other questions
Projects
None yet
Development

No branches or pull requests

6 participants