-
Notifications
You must be signed in to change notification settings - Fork 13.8k
If a trait item appears in rustdoc search, hide the corrosponding impl items #145898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
If a trait item appears in rustdoc search, hide the corrosponding impl items #145898
Conversation
This comment has been minimized.
This comment has been minimized.
738dcc9
to
8444219
Compare
this has been fixed (and removed from the PR description), i just needed to also be checking |
This comment has been minimized.
This comment has been minimized.
Right, I just remembered why my original design had its own deduplication pass, instead of leveraging the existing deduplication pass: if the user searches for |
8444219
to
0574e11
Compare
This comment has been minimized.
This comment has been minimized.
0574e11
to
0c19f15
Compare
I believe I managed to get it working using notriddle's idea for how the search index data should be structured, but with my original idea of having two deduplication passes. |
This comment has been minimized.
This comment has been minimized.
0c19f15
to
a78352a
Compare
This comment has been minimized.
This comment has been minimized.
ok so apparently some impls for unnamable traits get lowered and then filtered out later? which seems mildly wasteful but ig in the meantime i need to remove this debug assertion. |
a78352a
to
2cf6317
Compare
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
25836ae
to
8f00bd5
Compare
r? @notriddle rustbot has assigned @notriddle. Use |
Some changes occurred in GUI tests. Some changes occurred in HTML/CSS/JS. |
☔ The latest upstream changes (presumably #146700) made this pull request unmergeable. Please resolve the merge conflicts. |
8f00bd5
to
a45a03c
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
a45a03c
to
8f00bd5
Compare
This comment has been minimized.
This comment has been minimized.
8f00bd5
to
b297e37
Compare
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
} else { | ||
// FIXME: this is `O(n*m)` because we're repeatedly | ||
// shifting with Array.splice, but could be `O(n+m)` if | ||
// we did the shifting manually in a more clever way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it might be worth doing right away? Considering we're trying to improve the search performance (and we don't have a common way to test it ><), it'd be nice to know exactly the impact of this code to know if we should care or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea if it's worth it, but I'd be happy to implement it, since its an interesting algorithm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try to check in your web browser the amount of time this function takes? They have nice performance recording tools, that would give already a pretty good idea. If it takes like 1% of the total, it's not really worth it.
There isn't a test to ensure that items are hidden right? Or did I miss it? |
There is no test currently, I will add one. |
This comment has been minimized.
This comment has been minimized.
b9e60a2
to
84a6282
Compare
// FIXME: this is `O(n*m)` because we're repeatedly | ||
// shifting with Array.splice, but could be `O(n+m)` if | ||
// we did the shifting manually in a more clever way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to bring up MAX_RESULTS
, which means n
can never exceed 20.
define-function: ( | ||
"check-search-color", | ||
[ | ||
theme, count_color, desc_color, path_color, bottom_border_color, keyword_color, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused. Why is this being removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not, it's being moved to check-alias. This unit test seemed really unreliable, and honestly I'm not entirely sure how it was passing in the first place.
for example, if we're showing `Iterator::next`, we don't need to also show `Range::next` in the results.
84a6282
to
1adb51f
Compare
fixes #138251
cc @notriddle