rustdoc-search: add impl disambiguator to duplicate assoc items

[notriddle]

Preview (to see the difference, click the link and pay attention to the specific function that comes up):

Before	After
simd<i64>, simd<i64> -> simd<i64>	simd<i64>, simd<i64> -> simd<i64>
cow, vec -> bool	cow, vec -> bool

Helps with #90929

This changes the search results, specifically, when there's more than one impl with an associated item with the same name. For example, the search queries simd<i8> -> simd<i8> and simd<i64> -> simd<i64> don't link to the same function, but most of the functions have the same names.

This change should probably be FCP-ed, especially since it adds a new anchor link format for main.js to handle, so that URLs like struct.Vec.html#impl-AsMut<[T]>-for-Vec<T,+A>/method.as_mut redirect to struct.Vec.html#method.as_mut-2. It's a strange design, but there are a few reasons for it:

• I'd like to avoid making the HTML bigger. Obviously, fixing this bug is going to add at least a little more data to the search index, but adding more HTML penalises viewers for the benefit of searchers.

• Breaking struct.Vec.html#method.len would also be a disappointment.

On the other hand:

• The path-style anchors might be less prone to link rot than the numbered anchors. It's definitely less likely to have URLs that appear to "work", but silently point at the wrong thing.

• This commit arranges the path-style anchor to redirect to the numbered anchor. Nothing stops rustdoc from doing the opposite, making path-style anchors the default and redirecting the "legacy" numbered ones.

The bug

On the "Before" links, this example search calls for i64:

But if I click any of the results, I get f64 instead.

The PR fixes this problem by adding enough information to the search result href to disambiguate methods with different types but the same name.

More detailed description of the problem at:
#109422 (comment)

When a struct/enum/union has multiple impls with different type parameters, it can have multiple methods that have the same name, but which are on different impls. Besides Simd, Any also demonstrates this pattern. It has three methods named downcast, on three different impls.

When that happens, it presents a challenge in linking to the method. Normally we link like #method.foo. When there are multiple foo, we number them like #method.foo, #method.foo-1, #method.foo-2, etc.

It also presents a challenge for our search code. Currently we store all the variants in the index, but don’t have any way to generate unambiguous URLs in the results page, or to distinguish them in the SERP.

To fix this, we need three things:

1. A fragment format that fully specifies the impl type parameters when needed to disambiguate (#impl-SimdOrd-for-Simd<i64,+LANES>/method.simd_max)
2. A search index that stores methods with enough information to disambiguate the impl they were on.
3. A search results interface that can display multiple methods on the same type with the same name, when appropriate OR a disambiguation landing section on item pages?

For reviewers: it can be hard to see the new fragment format in action since it immediately gets rewritten to the numbered form.

[rustbot]

r? @jsha

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

[rustbot]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez, @Folyd, @jsha

[GuillaumeGomez]

Just checked and it looks pretty nice. One thing though (a GUI test to be added for this too): when clicking on the std::borrow::Cow::eq link, when we arrive on the page, the focused element isn't highlighted.

[notriddle]

@GuillaumeGomez A fix has been committed and an update pushed to the preview.

[GuillaumeGomez]

It's a really nice improvement! It's a shame that we need to add JS to handle this but considering that the alternative would be to increase significantly the HTML size, I think it's an acceptable tradeoff.

Let's see what others think about it.

@rfcbot fcp merge

[rfcbot]

Team member @GuillaumeGomez has proposed to merge this. The next step is review by the rest of the tagged team members:

• @GuillaumeGomez
• @Manishearth
• @Nemo157
• @aDotInTheVoid
• @camelid
• @jsha
• @notriddle

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[jsha]

Restating the problem for my own understanding. Maybe you want to incorporate some of this in the PR desc as an intro?

When a struct/enum/union has multiple impls with different type parameters, it can have multiple methods that have the same name, but which are on different impls. Besides Simd, Any also demonstrates this pattern. It has three methods named downcast, on three different impls.

When that happens, it presents a challenge in linking to the method. Normally we link like #method.foo. When there are multiple foo, we number them like #method.foo, #method.foo-1, #method.foo-2, etc.

It also presents a challenge for our search code. Currently we only store one of the various foo methods in the search index(?).

To fix this, we need three things:

1. A fragment format that fully specifies the impl type parameters when needed to disambiguate (#impl-SimdOrd-for-Simd<i64,+LANES>/method.simd_max)
2. A search index that stores methods with enough information to disambiguate the impl they were on.
3. A search results interface that can display multiple methods on the same type with the same name, when appropriate OR a disambiguation landing section on item pages?

I thought we already had an old PR floating around for (1)? Also FYI for any other reviewers, it can be hard to see the new fragment format in action because on page load the fragment immediately gets rewritten to the old-style format.

Anyhow in general I like the idea. I'd kind of like the fully-specified fragment format to be the default, because it's more stable. But it would also be nice for single-impl structs to be able to use the simpler #method.foo format.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[GuillaumeGomez]

@notriddle Feel free to r+ if it's all good (I saw you pushed a few commits recently so just in case...).

[notriddle]

I was just rebasing with the other changes to search.

@bors r+ rollup

[bors]

📌 Commit 2a4c9d0 has been approved by notriddle

It is now in the queue for this repository.

[notriddle]

@bors r-

@bors r=@GuillaumeGomez rollup

[bors]

📌 Commit 2a4c9d0 has been approved by GuillaumeGomez

It is now in the queue for this repository.