rustdoc-search: count path edits with separate edit limit

[notriddle]

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.

[rustbot]

r? @jsha

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez, @jsha

[GuillaumeGomez]

Change look good to me. Can you run JS perf check too please?

[notriddle]

@GuillaumeGomez

https://notriddle.com/rustdoc-html-demo-8/path-edit-distance-prof

[GuillaumeGomez]

There isn't really a case "like std" right?

[notriddle]

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.

Project	Search index size
ripgrep benchmark	552K
standard library docs	4.8M
arti benchmark 1	9.1M
compiler-docs 2	11M
https://doc.servo.org/search-index.js 3 2	38M
stm32f4 benchmark 1	61M

Footnotes

1. this benchmark includes all transitive dependencies and all features; the arti docs published by the Tor project, and stm32f4 docs on docs.rs, are smaller because they don't ↩ ↩²

2. not currently part of the benchmark suite, because it also requires unstable compiler features, and I've been avoiding unstable features in the benchmark suite to make my life easier ↩ ↩²

3. servo actually does include all of their transitive dependencies in their officially-published docs ↩

[GuillaumeGomez]

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]

📌 Commit 0ea58e2 has been approved by GuillaumeGomez

It is now in the queue for this repository.

[bors]

⌛ Testing commit 0ea58e2 with merge 5c0907b...

[bors]

💥 Test timed out

[notriddle]

@bors retry

dist-apple-various timed out on #119359 too.

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)