rustdoc: Primitive data type methods like min/max/clamp are not discoverable

[dwbuiten]

Currently, searching the rust stdlib docs for, as an example, 'i32 min', will not find any info at all, and the the i32 page (https://doc.rust-lang.org/std/primitive.i32.html) is not searchable with standard CTRL-F in some browsers like Firefox, since min/max/clamp are hidden under the by-default-collapsed section on Ord. This lack of searchability/discoverability extends to Google results.

I'm not sure what the bets method to remedy this is, but fixing the on-site search to know about these is probably a good start.

[the8472]

There's basically a difference between searching for a method and looking whether certain trait implementations exist for a type.

Maybe implemented traits and trait methods should be listed separately. Then one could have a list of all available methods (annotated with trait bounds and which trait they come from) and a list of implemented traits.

[dwbuiten]

I can't speak for the approach or implementation, but the outcome you describe sounds desireable, to me, anyway.

[czipperz]

I might add that I have been running into this issue a lot recently. I think at some point recently the docs for traits were automatically collapsed.

[GuillaumeGomez]

The rustdoc search is very basic. If you're looking for something with whitespaces in the request, it'll very likely not work. In your case, maybe try "i32::min"?

Otherwise, I don't really see how to fix this issue... :-/

[dwbuiten]

Having to type in something so exact (and like I said, this affects Google results too!) is not very useful for discoverability. This especially effects people who are new to Rust, like myself.

[GuillaumeGomez]

I understand your problem, I'm just telling you that I don't know how to solve it. We can't embedded a powerful parser and certainly not an NLP one...

[the8472]

this affects Google results too!

I think that particular issue could be fixed by using HTML's <details>/<summary>, which will hide the collapsed content from the user but not from the search engines.

[lu-zero]

If we want to go on the overkill side we could have tiny engines like sonic or tinysearch.

But to make the problem less impacting in the short term it would be enough to map the search query on the existing index to the query and an additional one with spaces replaced with ::.

[GuillaumeGomez]

If it's not fully embeddable in the front, then it's very likely we won't give it a look. We want to keep rustdoc able to work locally without an internet connection.

[lu-zero]

both can be compiled to wasm, but it really boils down to change how the query behaves in front of spaces between words.

[GuillaumeGomez]

The search engine is in src/librustdoc/html/static/main.js if you want to take a look. Any idea is very welcome. :)

[czipperz]

src/librustdoc/html/static/main.js

[lu-zero]

javascript is not my favourite language and that file isn't exactly short.

If you could point me to where the search term are managed I can try to add the 5 ugly lines to generate additional items from the initial search string, but I'm quite sure that who wrote that would be much quicker than me in doing that.

[pickfire]

Why not tinysearch? I bet it could speed up the search timings, right now I still feel some latency from rustdoc searches. Hopefully the speedup is as much as switching from JS parsing to JSON parsing.