rustdoc-search: count path edits with separate edit limit #119331
Merged
+152
−44
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @jsha (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
Some changes occurred in HTML/CSS/JS. cc @GuillaumeGomez, @jsha |
This comment has been minimized.
This comment has been minimized.
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.
notriddle
force-pushed
the
notriddle/maxpatheditdistance
branch
from
91f41b8
to
0ea58e2
Compare
|
Change look good to me. Can you run JS perf check too please? |
|
There isn't really a case "like std" right? |
|
I haven't included the standard library in this benchmark tool, because rigging it up would be complicated and not worth it. The complexity comes from it being developed alongside the compiler, which means if I want to do a comparison benchmark across a bootstrap compiler version bump, I can't build the same version of the standard library with two different versions of rustdoc (unstable features are unstable) but I also shouldn't try to compare two different versions of the standard library (not an apples-to-apples comparison of the search engine changes). The other reason is that the standard library isn't small enough to be a microbenchmark, or big enough to be a stress test.
Footnotes
|
|
That's a good point. Well, let's consider the bench results not changing as a green light for going forward with it then. Thanks! @bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 28, 2023
…nce, r=GuillaumeGomez rustdoc-search: count path edits with separate edit limit Avoids strange-looking results like this one, where the path component seems to be ignored:  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. This commit also adds substring matching to paths. It's stricter than the substring matching in the main part, but loose enough that what I expect to match does. Queries without parent paths are unchanged.
|
💥 Test timed out |
bors
added
S-waiting-on-review
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 28, 2023
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#119331 (rustdoc-search: count path edits with separate edit limit) - rust-lang#119359 (Simplify Parser::ident_or_error) - rust-lang#119376 (Add regression test for rust-lang#106630) - rust-lang#119379 (Update `parse_seq` doc) - rust-lang#119380 (Don't suggest writing a bodyless arm if the pattern can never be a never pattern) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 28, 2023
Rollup merge of rust-lang#119331 - notriddle:notriddle/maxpatheditdistance, r=GuillaumeGomez rustdoc-search: count path edits with separate edit limit Avoids strange-looking results like this one, where the path component seems to be ignored:  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. This commit also adds substring matching to paths. It's stricter than the substring matching in the main part, but loose enough that what I expect to match does. Queries without parent paths are unchanged.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Avoids strange-looking results like this one, where the path component seems to be ignored:
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:
Of course,
slice::itermutshould not match stuff from btreemap.sliceshould not matchstd.The new result counts them separately:
Effectively, this makes path queries less "typo-resistant". It's not zero, but it means
vecwon't match thev1prelude.This commit also adds substring matching to paths. It's stricter than the substring matching in the main part, but loose enough that what I expect to match does.
Queries without parent paths are unchanged.