When writing a type-driven search query in rustdoc, specifically one
with more than one query element, non-existent types become generic
parameters instead of auto-correcting (which is currently only done
for single-element queries) or giving no result. You can also force a
generic type parameter by writing `generic:T` (and can force it to not
use a generic type parameter with something like `struct:T` or whatever,
though if this happens it means the thing you're looking for doesn't
exist and will give you no results).
There is no syntax provided for specifying type constraints
for generic type parameters.
When you have a generic type parameter in a search query, it will only
match up with generic type parameters in the actual function, not
concrete types that match, not concrete types that implement a trait.
It also strictly matches based on when they're the same or different,
so `option<T>, option<U> -> option<U>` matches `Option::and`, but not
`Option::or`. Similarly, `option<T>, option<T> -> option<T>`` matches
`Option::or`, but not `Option::and`.
rustdoc-search: clean up type unification and "unboxing"
This PR redesigns parameter matching, return matching, and generics matching to use a single function that compares two lists of types.
It also makes the algorithms more consistent, so the "unboxing" behavior where `Vec<i32>` is considered a match for `i32` works inside generics, and not just at the top level.
This feature extends rustdoc to support the syntax that most users will
naturally attempt to use to search for diverging functions.
Part of #60485
It's already possible to do this search with `primitive:never`, but
that's not what the Rust language itself uses, so nobody will try it if
they aren't told or helped along.
rustdoc-search: add slices and arrays to index
This indexes them as primitives with generics, so `slice<u32>` is how you search for `[u32]`, and `array<u32>` for `[u32; 1]`. A future commit will desugar the square bracket syntax to search both arrays and slices at once.
This indexes them as primitives with generics, so `slice<u32>` is
how you search for `[u32]`, and `array<u32>` for `[u32; 1]`.
A future commit will desugar the square bracket syntax to search
both arrays and slices at once.
This change makes it so, instead of mixing string distance with
type unification, function signature search works by
mapping names to IDs at the start, reporting to the user any
cases where it had to make corrections, and then matches with
IDs when going through the items.
This only changes function searches. Name searches are left alone,
and corrections are only done when there's a single item in the
search query.
This makes sense, since the search index has the information in it,
and it's more useful for function signature searches since a
function signature search's item type is, by definition, some type
of function (there's more than one, but not very many).
This tweak to the function signature search engine makes things so that,
if a type is repeated in the search query, it'll only match if the
function actually includes it that many times.
