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

[mihneadb]

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]

r? @brson

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

[mihneadb]

r? @alexcrichton

[bluss]

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

[mihneadb]

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]

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

[mihneadb]

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]

Checked, the index is compressed:

[alexcrichton]

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]

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]

@alexcrichton what's your verdict?

[alexcrichton]

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]

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.