rustdoc search: invalid "in parameters" results for "streaming"

[jsha]

Steps to reproduce:

1. Search for "streaming" in the hyper docs: https://docs.rs/hyper/0.14.25/hyper/index.html?search=streaming (built with 2023-03-09 nightly rustdoc).

Expected results:

Either a struct with Streaming in the name appears, or no results.

Actual results:

Search page automatically shows the "In parameters" tab, and it contains results for several functions that don't mention "streaming" in their parameters.

[notriddle]

It looks like these are "legit" matches, according to the edit distance function, for the word "string", which appears in all of the returned matches, because it has an edit distance of 3 (streaming).

Do you think it would be better to make "In parameters" and "in return types" not do fuzzy name matching, regardless of the complexity of the query? It would certainly make the search code simpler!

Note: while some of those links seem to point at functions with no "string" in their type signatures, that's just #109422 showing up, and there are functions with the same name on that page that have "string" in their type signatures.

Corrected links to all the functions

• hyper::body::Bytes::eq
• hyper::header::HeaderValue::eq
• hyper::body::Body::from
• hyper::body::Bytes::from
• hyper::Uri::try_from
• hyper::ext::ReasonPhrase::try_from
• hyper::header::HeaderName::try_from
• hyper::header::HeaderValue:::try_from
• hyper::body::Bytes::partial_cmp
• hyper::header::HeaderValue::partial_cmp

The exception is this one, with "stream" (which obviously is a good match for "streaming"):

• hyper::server::accept::from_stream

[jsha]

Probably the biggest problem here is that "In parameters" and "In return types" don't show the function signatures that are being matched against, so it's hard to understand why a given function might match. I think it would be good to show those function signatures. That does imply longer, multiline search results for those two tabs, so they'd have a significantly different UI than the default tab. But I think that's okay.

I also think it's counterintuitive that we automatically jump to "In parameters" and "In return types" when there are no results for the default tab. I think we should only switch to those tabs on explicit user request.

The other thing is that streaming feels like a bad match for string. Perhaps it's because all of the "edits" are in a row, or perhaps it's because they are all insertions. It would be very unusual for someone to typo adding three letters in sequence (and expect it to still match).