2021-12-16 21:17:22 -08:00
|
|
|
// This file contains type definitions that are processed by the Closure Compiler but are
|
|
|
|
// not put into the JavaScript we include as part of the documentation. It is used for
|
|
|
|
// type checking. See README.md in this directory for more info.
|
|
|
|
|
|
|
|
/* eslint-disable */
|
2022-04-25 14:23:06 +02:00
|
|
|
let searchState;
|
2021-12-16 21:17:22 -08:00
|
|
|
function initSearch(searchIndex){}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @typedef {{
|
2021-12-20 15:42:08 +01:00
|
|
|
* name: string,
|
2023-06-15 13:55:45 -07:00
|
|
|
* id: integer|null,
|
2021-12-20 15:42:08 +01:00
|
|
|
* fullPath: Array<string>,
|
|
|
|
* pathWithoutLast: Array<string>,
|
|
|
|
* pathLast: string,
|
|
|
|
* generics: Array<QueryElement>,
|
2023-09-22 17:27:06 -07:00
|
|
|
* bindings: Map<(string|integer), Array<QueryElement>>,
|
2021-12-20 15:42:08 +01:00
|
|
|
* }}
|
|
|
|
*/
|
2022-04-25 14:23:06 +02:00
|
|
|
let QueryElement;
|
2021-12-20 15:42:08 +01:00
|
|
|
|
2022-01-04 15:44:00 +01:00
|
|
|
/**
|
|
|
|
* @typedef {{
|
|
|
|
* pos: number,
|
|
|
|
* totalElems: number,
|
|
|
|
* typeFilter: (null|string),
|
|
|
|
* userQuery: string,
|
2023-09-22 17:27:06 -07:00
|
|
|
* isInBinding: (null|string),
|
2022-01-04 15:44:00 +01:00
|
|
|
* }}
|
|
|
|
*/
|
2022-04-25 14:23:06 +02:00
|
|
|
let ParserState;
|
2022-01-04 15:44:00 +01:00
|
|
|
|
2021-12-20 15:42:08 +01:00
|
|
|
/**
|
|
|
|
* @typedef {{
|
|
|
|
* original: string,
|
2022-01-03 16:43:30 +01:00
|
|
|
* userQuery: string,
|
2021-12-20 15:42:08 +01:00
|
|
|
* typeFilter: number,
|
|
|
|
* elems: Array<QueryElement>,
|
|
|
|
* args: Array<QueryElement>,
|
|
|
|
* returned: Array<QueryElement>,
|
|
|
|
* foundElems: number,
|
2023-08-05 11:22:21 -07:00
|
|
|
* totalElems: number,
|
2023-04-15 11:53:50 -07:00
|
|
|
* literalSearch: boolean,
|
|
|
|
* corrections: Array<{from: string, to: integer}>,
|
2021-12-16 21:17:22 -08:00
|
|
|
* }}
|
|
|
|
*/
|
2022-04-25 14:23:06 +02:00
|
|
|
let ParsedQuery;
|
2021-12-16 21:17:22 -08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @typedef {{
|
|
|
|
* crate: string,
|
|
|
|
* desc: string,
|
|
|
|
* id: number,
|
|
|
|
* name: string,
|
|
|
|
* normalizedName: string,
|
|
|
|
* parent: (Object|null|undefined),
|
|
|
|
* path: string,
|
|
|
|
* ty: (Number|null|number),
|
2023-06-02 19:58:44 -07:00
|
|
|
* type: FunctionSearchType?
|
2021-12-16 21:17:22 -08:00
|
|
|
* }}
|
|
|
|
*/
|
2022-04-25 14:23:06 +02:00
|
|
|
let Row;
|
2022-01-04 15:44:00 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @typedef {{
|
|
|
|
* in_args: Array<Object>,
|
|
|
|
* returned: Array<Object>,
|
|
|
|
* others: Array<Object>,
|
|
|
|
* query: ParsedQuery,
|
|
|
|
* }}
|
|
|
|
*/
|
2022-04-25 14:23:06 +02:00
|
|
|
let ResultsTable;
|
2022-01-04 15:44:00 +01:00
|
|
|
|
2023-04-13 17:05:12 -07:00
|
|
|
/**
|
|
|
|
* @typedef {Map<String, ResultObject>}
|
|
|
|
*/
|
|
|
|
let Results;
|
|
|
|
|
2022-01-04 15:44:00 +01:00
|
|
|
/**
|
|
|
|
* @typedef {{
|
|
|
|
* desc: string,
|
|
|
|
* displayPath: string,
|
|
|
|
* fullPath: string,
|
|
|
|
* href: string,
|
|
|
|
* id: number,
|
|
|
|
* lev: number,
|
|
|
|
* name: string,
|
|
|
|
* normalizedName: string,
|
|
|
|
* parent: (Object|undefined),
|
|
|
|
* path: string,
|
|
|
|
* ty: number,
|
|
|
|
* }}
|
|
|
|
*/
|
2023-04-13 17:05:12 -07:00
|
|
|
let ResultObject;
|
2022-06-27 11:07:16 -07:00
|
|
|
|
|
|
|
/**
|
2022-06-27 12:07:13 -07:00
|
|
|
* A pair of [inputs, outputs], or 0 for null. This is stored in the search index.
|
2022-06-27 11:07:16 -07:00
|
|
|
* The JavaScript deserializes this into FunctionSearchType.
|
|
|
|
*
|
2022-06-27 14:13:13 -07:00
|
|
|
* Numeric IDs are *ONE-indexed* into the paths array (`p`). Zero is used as a sentinel for `null`
|
|
|
|
* because `null` is four bytes while `0` is one byte.
|
|
|
|
*
|
2022-06-27 11:07:16 -07:00
|
|
|
* An input or output can be encoded as just a number if there is only one of them, AND
|
|
|
|
* it has no generics. The no generics rule exists to avoid ambiguity: imagine if you had
|
|
|
|
* a function with a single output, and that output had a single generic:
|
|
|
|
*
|
|
|
|
* fn something() -> Result<usize, usize>
|
|
|
|
*
|
rustdoc-search: add support for type parameters
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`.
2023-06-16 14:43:28 -07:00
|
|
|
* If output was allowed to be any RawFunctionType, it would look like thi
|
2022-06-27 11:07:16 -07:00
|
|
|
*
|
|
|
|
* [[], [50, [3, 3]]]
|
|
|
|
*
|
|
|
|
* The problem is that the above output could be interpreted as either a type with ID 50 and two
|
|
|
|
* generics, or it could be interpreted as a pair of types, the first one with ID 50 and the second
|
|
|
|
* with ID 3 and a single generic parameter that is also ID 3. We avoid this ambiguity by choosing
|
|
|
|
* in favor of the pair of types interpretation. This is why the `(number|Array<RawFunctionType>)`
|
|
|
|
* is used instead of `(RawFunctionType|Array<RawFunctionType>)`.
|
|
|
|
*
|
rustdoc-search: add support for type parameters
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`.
2023-06-16 14:43:28 -07:00
|
|
|
* The output can be skipped if it's actually unit and there's no type constraints. If thi
|
|
|
|
* function accepts constrained generics, then the output will be unconditionally emitted, and
|
|
|
|
* after it will come a list of trait constraints. The position of the item in the list will
|
|
|
|
* determine which type parameter it is. For example:
|
|
|
|
*
|
|
|
|
* [1, 2, 3, 4, 5]
|
|
|
|
* ^ ^ ^ ^ ^
|
|
|
|
* | | | | - generic parameter (-3) of trait 5
|
|
|
|
* | | | - generic parameter (-2) of trait 4
|
|
|
|
* | | - generic parameter (-1) of trait 3
|
|
|
|
* | - this function returns a single value (type 2)
|
|
|
|
* - this function takes a single input parameter (type 1)
|
|
|
|
*
|
|
|
|
* Or, for a less contrived version:
|
|
|
|
*
|
|
|
|
* [[[4, -1], 3], [[5, -1]], 11]
|
|
|
|
* -^^^^^^^---- ^^^^^^^ ^^
|
|
|
|
* | | | - generic parameter, roughly `where -1: 11`
|
|
|
|
* | | | since -1 is the type parameter and 11 the trait
|
|
|
|
* | | - function output 5<-1>
|
|
|
|
* | - the overall function signature is something like
|
|
|
|
* | `fn(4<-1>, 3) -> 5<-1> where -1: 11`
|
|
|
|
* - function input, corresponds roughly to 4<-1>
|
|
|
|
* 4 is an index into the `p` array for a type
|
|
|
|
* -1 is the generic parameter, given by 11
|
|
|
|
*
|
|
|
|
* If a generic parameter has multiple trait constraints, it gets wrapped in an array, just like
|
|
|
|
* function inputs and outputs:
|
|
|
|
*
|
|
|
|
* [-1, -1, [4, 3]]
|
|
|
|
* ^^^^^^ where -1: 4 + 3
|
|
|
|
*
|
|
|
|
* If a generic parameter's trait constraint has generic parameters, it gets wrapped in the array
|
|
|
|
* even if only one exists. In other words, the ambiguity of `4<3>` and `4 + 3` is resolved in
|
|
|
|
* favor of `4 + 3`:
|
|
|
|
*
|
|
|
|
* [-1, -1, [[4, 3]]]
|
|
|
|
* ^^^^^^^^ where -1: 4 + 3
|
|
|
|
*
|
|
|
|
* [-1, -1, [5, [4, 3]]]
|
|
|
|
* ^^^^^^^^^^^ where -1: 5, -2: 4 + 3
|
|
|
|
*
|
|
|
|
* If a generic parameter has no trait constraints (like in Rust, the `Sized` constraint i
|
|
|
|
* implied and a fake `?Sized` constraint used to note its absence), it will be filled in with 0.
|
|
|
|
*
|
2022-06-27 11:07:16 -07:00
|
|
|
* @typedef {(
|
|
|
|
* 0 |
|
|
|
|
* [(number|Array<RawFunctionType>)] |
|
rustdoc-search: add support for type parameters
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`.
2023-06-16 14:43:28 -07:00
|
|
|
* [(number|Array<RawFunctionType>), (number|Array<RawFunctionType>)] |
|
|
|
|
* Array<(number|Array<RawFunctionType>)>
|
2022-06-27 11:07:16 -07:00
|
|
|
* )}
|
|
|
|
*/
|
|
|
|
let RawFunctionSearchType;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A single function input or output type. This is either a single path ID, or a pair of
|
|
|
|
* [path ID, generics].
|
|
|
|
*
|
2022-06-27 14:13:13 -07:00
|
|
|
* Numeric IDs are *ONE-indexed* into the paths array (`p`). Zero is used as a sentinel for `null`
|
|
|
|
* because `null` is four bytes while `0` is one byte.
|
|
|
|
*
|
2022-06-27 11:07:16 -07:00
|
|
|
* @typedef {number | [number, Array<RawFunctionType>]}
|
|
|
|
*/
|
|
|
|
let RawFunctionType;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @typedef {{
|
|
|
|
* inputs: Array<FunctionType>,
|
2023-06-02 19:58:44 -07:00
|
|
|
* output: Array<FunctionType>,
|
rustdoc-search: add support for type parameters
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`.
2023-06-16 14:43:28 -07:00
|
|
|
* where_clause: Array<Array<FunctionType>>,
|
2022-06-27 11:07:16 -07:00
|
|
|
* }}
|
|
|
|
*/
|
|
|
|
let FunctionSearchType;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @typedef {{
|
2023-04-15 11:53:50 -07:00
|
|
|
* id: (null|number),
|
2023-09-22 17:27:06 -07:00
|
|
|
* ty: number,
|
2022-06-27 11:07:16 -07:00
|
|
|
* generics: Array<FunctionType>,
|
2023-09-22 17:27:06 -07:00
|
|
|
* bindings: Map<integer, Array<FunctionType>>,
|
2022-06-27 11:07:16 -07:00
|
|
|
* }}
|
|
|
|
*/
|
|
|
|
let FunctionType;
|