-
Couldn't load subscription status.
- Fork 13.9k
Description
Code
// lib.rs of a normal cargo project `cargo new --lib rustdoc_repro`
pub struct Foo;
impl Foo {
pub fn bar_first() {}
pub fn bar_last() {}
}
pub struct Quux;
impl Quux {
#[doc(alias = "bar_first")]
pub fn phooey1() {}
#[doc(alias = "bar_etc")]
pub fn phooey2() {}
}Reproduction Steps
cargo +nightly doc --open- Search for
Foo::bar
Expected Outcome
When searching Foo::bar, Foo::bar_first and Foo::bar_last should be prioritized over Quux::phooey1 and Quux::phooey2 (if those are shown at all).
Actual Output
The methods are shown in this order in the search results:
bar_etc - see rustdoc_repro::Quux::phooey2rustdoc_repro::Foo::bar_lastbar_first - see rustdoc_repro::Quux::phooey1rustdoc_repro::Foo::bar_first
Version
$ rustdoc +nightly --version --verbose
rustdoc 1.91.0-nightly (69b76df90 2025-08-23)
binary: rustdoc
commit-hash: 69b76df90c7ea63b5350d1865f92902a0b27c9a2
commit-date: 2025-08-23
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0@rustbot label A-rustdoc-search
Additional Details
Related to #140968, but in that example there is no leading type, and that issue has been since before 1.87.0.
Bisected: the behavior changed in #144476, before that count_ones didn't show up in the search results for BTreeSet::pop at all.
This is minimzed from the stdlib nightly docs, where I searched for BTreeSet::pop and got 18 different popcnt - see integer::count_ones methods before BTreeSet::pop_first and BTreeSet::pop_last (which were what I was looking for).
