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

[Rustdoc] save generic type data to index + basic search #26356

Closed
wants to merge 6 commits into from

Conversation

mihneadb
Copy link
Contributor

This PR adds more complex type data for generics to the search index, such as:

            {
                "inputs": [
                    {
                        "name": "t",
                        "generic": "true",
                        "ty_params": []
                    }
                ],
                "output": {
                    "name": "t",
                    "generic": "true",
                    "ty_params": []
                }
            }

for fn identity<T>(x: T) -> T, and

            {
                "inputs": [
                    {
                        "name": "option",
                        "generic": "true",
                        "ty_params": [
                            {
                                "name": "t",
                                "generic": "true",
                                "ty_params": []
                            }
                        ]
                    }
                ],
                "output": {
                    "name": "i32",
                    "generic": "false",
                    "ty_params": []
                }
            }

for fn generic_option_stuff<T>(x: Option<T>) -> i32

On the frontend side, searches such as char -> char will match the identity function above. Similarly, string, string -> will match std::env::set_var. So the search logic only tries to particularize generic types against the given query. It only does so for "base" generic types (i.e. T, not Option<T>) -- but the information for this is already in the index, it's only the JS logic that needs improving.

A problem that I couldn't figure out how to solve is getting the full type information for self. Currently, we have access to the type's name (via the parent stack, implemented in #23289), but that means for example that for a method on something like MyOption<T> we only get name: myoption, generic: false. Also, please note that this does not take trait bounds into account. (#mvp)

cc @alexcrichton

@rust-highfive
Copy link
Collaborator

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@mihneadb
Copy link
Contributor Author

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned brson Jun 18, 2015
@@ -253,16 +253,26 @@ struct IndexItem {
/// A type used for the search index.
struct Type {
name: Option<String>,
// true both for Option<T> and T, false otherwise.
generic: bool,
ty_params: Box<Vec<Type>>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why Box<Vec<..>>? This is only useful in rare cases, Vec itself is already only three usize large.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I didn't know any better :). It was Box<Type> initially to avoid infinite recursion, and when I changed to Vec I didn't reconsider the Box. Will change, thanks!

@bluss
Copy link
Member

bluss commented Jun 18, 2015

What's the impact on the search index file size? This is especially interesting/important for libstd.

@mihneadb
Copy link
Contributor Author

make docs on master yields a 1.9MB search index. Running it on this branch results in a 2.2MB file. I think doc.rust-lang gzips static files anyway (doesn't it?).

@mihneadb
Copy link
Contributor Author

Checked, the index is compressed:
screenshot 2015-06-20 05 20 30

@alexcrichton
Copy link
Member

I'm somewhat wary about how we can effectively make use of this in searches, it looks like you want to match generic functions against searching for a signature, but there's no guarantee that generics with a bound are actually satisfied as part of the query, so it's possible to get a lot of bogus examples, right?

@mihneadb
Copy link
Contributor Author

That's correct, trait bounds are not handled in any way. I felt it would be too big of a project in itself and that this could be done incrementally. However, if you think it might not be too useful as it is, feel free to close this and maybe it can be reused later 😄.

@Gankra
Copy link
Contributor

Gankra commented Jul 27, 2015

@alexcrichton what's your verdict?

@alexcrichton
Copy link
Member

Ok, I'm a little worried about how the search is fairly lossy (doesn't match bounds, may not work on self types, etc), so I'm going to close this for now. We can certainly always re-investigate if this comes up again!

@bluss
Copy link
Member

bluss commented Jul 27, 2015

Haskell's hoogle is a separate project, I think (separate from their doc generator)? Maybe this too could develop faster and more productively as a separate project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants