2023-09-09 18:49:29 -05:00
|
|
|
// ignore-order
|
|
|
|
|
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 16:43:28 -05:00
|
|
|
const FILTER_CRATE = "std";
|
|
|
|
|
2023-03-07 12:21:12 -06:00
|
|
|
const EXPECTED = [
|
|
|
|
{
|
2023-06-09 09:49:38 -05:00
|
|
|
'query': 'option, fnonce -> option',
|
2023-03-07 12:21:12 -06:00
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'map',
|
|
|
|
'displayType': '`Option`<T>, F -> `Option`<U>',
|
|
|
|
'displayWhereClause': "F: `FnOnce` (T) -> U",
|
|
|
|
},
|
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'option<t>, fnonce -> option',
|
|
|
|
'others': [
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'map',
|
|
|
|
'displayType': '`Option`<`T`>, F -> `Option`<U>',
|
|
|
|
'displayWhereClause': "F: `FnOnce` (T) -> U",
|
|
|
|
},
|
2023-03-07 12:21:12 -06:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
2023-06-09 09:49:38 -05:00
|
|
|
'query': 'option -> default',
|
2023-03-07 12:21:12 -06:00
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'unwrap_or_default',
|
|
|
|
'displayType': '`Option`<T> -> `T`',
|
|
|
|
'displayWhereClause': "T: `Default`",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'get_or_insert_default',
|
|
|
|
'displayType': '&mut `Option`<T> -> &mut `T`',
|
|
|
|
'displayWhereClause': "T: `Default`",
|
|
|
|
},
|
2023-03-07 12:21:12 -06:00
|
|
|
],
|
|
|
|
},
|
2023-05-25 14:58:36 -05:00
|
|
|
{
|
|
|
|
'query': 'option -> []',
|
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'as_slice',
|
|
|
|
'displayType': '&`Option`<T> -> &`[`T`]`',
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'as_mut_slice',
|
|
|
|
'displayType': '&mut `Option`<T> -> &mut `[`T`]`',
|
|
|
|
},
|
2023-05-25 14:58:36 -05:00
|
|
|
],
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
{
|
|
|
|
'query': 'option<t>, option<t> -> option<t>',
|
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'or',
|
|
|
|
'displayType': '`Option`<`T`>, `Option`<`T`> -> `Option`<`T`>',
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'xor',
|
|
|
|
'displayType': '`Option`<`T`>, `Option`<`T`> -> `Option`<`T`>',
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'option<t>, option<u> -> option<u>',
|
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'and',
|
|
|
|
'displayType': '`Option`<`T`>, `Option`<`U`> -> `Option`<`U`>',
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
2023-09-09 18:49:29 -05:00
|
|
|
'query': 'option<t>, option<u> -> option<t>',
|
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 16:43:28 -05:00
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'and',
|
|
|
|
'displayType': '`Option`<`T`>, `Option`<`U`> -> `Option`<`U`>',
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'zip',
|
|
|
|
'displayType': '`Option`<`T`>, `Option`<`U`> -> `Option`<(`T`, U)>',
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
2024-09-24 20:18:01 -05:00
|
|
|
'query': 'option<t>, option<u> -> option<(t, u)>',
|
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 16:43:28 -05:00
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'zip',
|
2024-09-24 20:18:01 -05:00
|
|
|
'displayType': '`Option`<`T`>, `Option`<`U`> -> `Option`<`(T`, `U)`>',
|
2024-09-24 16:31:44 -05:00
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'option<t>, e -> result<t, e>',
|
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'ok_or',
|
|
|
|
'displayType': '`Option`<`T`>, `E` -> `Result`<`T`, `E`>',
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'path': 'std::result::Result',
|
|
|
|
'name': 'transpose',
|
|
|
|
'displayType': 'Result<`Option`<`T`>, `E`> -> Option<`Result`<`T`, `E`>>',
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'result<option<t>, e> -> option<result<t, e>>',
|
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::result::Result',
|
|
|
|
'name': 'transpose',
|
|
|
|
'displayType': '`Result`<`Option`<`T`>, `E`> -> `Option`<`Result`<`T`, `E`>>',
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'option<t>, option<t> -> bool',
|
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'eq',
|
|
|
|
'displayType': '&`Option`<`T`>, &`Option`<`T`> -> `bool`',
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'option<option<t>> -> option<t>',
|
|
|
|
'others': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'flatten',
|
|
|
|
'displayType': '`Option`<`Option`<`T`>> -> `Option`<`T`>',
|
|
|
|
},
|
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 16:43:28 -05:00
|
|
|
],
|
|
|
|
},
|
2023-08-05 13:22:21 -05:00
|
|
|
{
|
|
|
|
'query': 'option<t>',
|
|
|
|
'returned': [
|
2024-09-24 16:31:44 -05:00
|
|
|
{
|
|
|
|
'path': 'std::result::Result',
|
|
|
|
'name': 'ok',
|
|
|
|
'displayType': 'Result<T, E> -> `Option`<`T`>',
|
|
|
|
},
|
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'option<t>, (fnonce () -> u) -> option',
|
|
|
|
'others': [
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'map',
|
|
|
|
'displayType': '`Option`<`T`>, F -> `Option`<U>',
|
2024-09-24 20:18:01 -05:00
|
|
|
'displayMappedNames': `t = T, u = U`,
|
2024-09-24 16:31:44 -05:00
|
|
|
'displayWhereClause': "F: `FnOnce` (T) -> `U`",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'and_then',
|
|
|
|
'displayType': '`Option`<`T`>, F -> `Option`<U>',
|
2024-09-24 20:18:01 -05:00
|
|
|
'displayMappedNames': `t = T, u = U`,
|
2024-09-24 16:31:44 -05:00
|
|
|
'displayWhereClause': "F: `FnOnce` (T) -> Option<`U`>",
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'zip_with',
|
|
|
|
'displayType': 'Option<T>, `Option`<`U`>, F -> `Option`<R>',
|
2024-09-24 20:18:01 -05:00
|
|
|
'displayMappedNames': `t = U, u = R`,
|
2024-09-24 16:31:44 -05:00
|
|
|
'displayWhereClause': "F: `FnOnce` (T, U) -> `R`",
|
|
|
|
},
|
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
'query': 'option<t>, (fnonce () -> option<u>) -> option',
|
|
|
|
'others': [
|
|
|
|
{
|
|
|
|
'path': 'std::option::Option',
|
|
|
|
'name': 'and_then',
|
|
|
|
'displayType': '`Option`<`T`>, F -> `Option`<U>',
|
2024-09-24 20:18:01 -05:00
|
|
|
'displayMappedNames': `t = T, u = U`,
|
2024-09-24 16:31:44 -05:00
|
|
|
'displayWhereClause': "F: `FnOnce` (T) -> `Option`<`U`>",
|
|
|
|
},
|
2023-08-05 13:22:21 -05:00
|
|
|
],
|
|
|
|
},
|
2023-03-07 12:21:12 -06:00
|
|
|
];
|