2022-05-09 13:46:24 -05:00
|
|
|
// exact-check
|
|
|
|
|
|
|
|
|
|
const EXPECTED = {
|
rustdoc-search: count path edits with separate edit limit
Since the two are counted separately elsewhere, they should get
their own limits, too. The biggest problem with combining them
is that paths are loosely checked by not requiring every component
to match, which means that if they are short and matched loosely,
they can easily find "drunk typist" matches that make no sense,
like this old result:
std::collections::btree_map::itermut matching slice::itermut
maxEditDistance = ("slice::itermut".length) / 3 = 14 / 3 = 4
editDistance("std", "slice") = 4
editDistance("itermut", "itermut") = 0
4 + 0 <= 4 PASS
Of course, `slice::itermut` should not match stuff from btreemap.
`slice` should not match `std`.
The new result counts them separately:
maxPathEditDistance = "slice".length / 3 = 5 / 3 = 1
maxEditDistance = "itermut".length / 3 = 7 / 3 = 2
editDistance("std", "slice") = 4
4 <= 1 FAIL
Effectively, this makes path queries less "typo-resistant".
It's not zero, but it means `vec` won't match the `v1` prelude.
Queries without parent paths are unchanged.
2023-12-26 17:15:51 -06:00
|
|
|
'query': 'bbbbbb::ccccccc',
|
2022-05-09 13:46:24 -05:00
|
|
|
'others': [
|
|
|
|
|
// `ccccccc` is an exact match for all three of these.
|
|
|
|
|
// However `b` is a closer match for `bb` than for any
|
|
|
|
|
// of the others, so it ought to go first.
|
rustdoc-search: count path edits with separate edit limit
Since the two are counted separately elsewhere, they should get
their own limits, too. The biggest problem with combining them
is that paths are loosely checked by not requiring every component
to match, which means that if they are short and matched loosely,
they can easily find "drunk typist" matches that make no sense,
like this old result:
std::collections::btree_map::itermut matching slice::itermut
maxEditDistance = ("slice::itermut".length) / 3 = 14 / 3 = 4
editDistance("std", "slice") = 4
editDistance("itermut", "itermut") = 0
4 + 0 <= 4 PASS
Of course, `slice::itermut` should not match stuff from btreemap.
`slice` should not match `std`.
The new result counts them separately:
maxPathEditDistance = "slice".length / 3 = 5 / 3 = 1
maxEditDistance = "itermut".length / 3 = 7 / 3 = 2
editDistance("std", "slice") = 4
4 <= 1 FAIL
Effectively, this makes path queries less "typo-resistant".
It's not zero, but it means `vec` won't match the `v1` prelude.
Queries without parent paths are unchanged.
2023-12-26 17:15:51 -06:00
|
|
|
{ 'path': 'path_ordering::bbbbbb', 'name': 'Ccccccc' },
|
|
|
|
|
{ 'path': 'path_ordering::abbbbb', 'name': 'Ccccccc' },
|
|
|
|
|
{ 'path': 'path_ordering::dbbbbb', 'name': 'Ccccccc' },
|
2022-05-09 13:46:24 -05:00
|
|
|
],
|
|
|
|
|
};
|