Skip to content
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

Fix global search #46175

Merged
merged 1 commit into from
Nov 28, 2017
Merged

Fix global search #46175

merged 1 commit into from
Nov 28, 2017

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez changed the title Fix global search [WIP] Fix global search Nov 21, 2017
@GuillaumeGomez
Copy link
Member Author

Seems like it messes with generics.

@GuillaumeGomez GuillaumeGomez changed the title [WIP] Fix global search Fix global search Nov 21, 2017
@GuillaumeGomez
Copy link
Member Author

Ok, generics are working again. Added comments to avoid removing the same code again.

} else {
return MAX_LEV_DISTANCE + 1;
}
}
return lev_distance;
return lev_distance;//Math.ceil(total / done);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still wondering if I should return the lowest lev distance or if I should return the average lev value... Any preference?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see how returning the average would be better, but i'm not sure how effective it will be. A user would need to search for something with multiple generics (which i'm not sure works right now? a search for Result<File, Error> returns a lot of bad lev results before any of the functions that return that type show up) before the difference will even show up. I think we can leave this as-is for now and investigate it in the future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll leave the comment just in case then if you don't mind.

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 22, 2017
@@ -374,7 +375,7 @@
var valLower = query.query.toLowerCase(),
val = valLower,
typeFilter = itemTypeFromName(query.type),
results = {},
results = {}, results_in_args = {}, results_returned = {},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really an issue with this PR, but I don't like how there's inconsistent var styles being used with some functions having one var per line, and others using commas like they're going out of style.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I grouped them by "theme". But if you want I can put each on a line.

for (i = 0; i < results.length; ++i) {
if (results[i].id > -1) {
var added = false;
var obj = searchIndex[results[i].id];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of obj is this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same as anywhere else in the code using searchIndex? :p How would you name it?

var added = false;
var obj = searchIndex[results[i].id];
obj.lev = results[i].lev;
if (isType !== true || obj.type) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also not really an issue with this PR, but the isType !== true in an if thing really isn't saving you any speed of !isType.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't care. In principle it's faster since the comparison is explicit.

var out = [];
for (i = 0; i < results.length; ++i) {
if (results[i].id > -1) {
var added = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line seems like it was left behind by accident.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!

@bors
Copy link
Contributor

bors commented Nov 25, 2017

☔ The latest upstream changes (presumably #46081) made this pull request unmergeable. Please resolve the merge conflicts.

@GuillaumeGomez
Copy link
Member Author

Rebased.

@QuietMisdreavus
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Nov 27, 2017

📌 Commit 0a12198 has been approved by QuietMisdreavus

@kennytm
Copy link
Member

kennytm commented Nov 27, 2017

I suggest we backport this (and possibly #46081 also) to 1.23-beta, as search is broken on beta as well.

@QuietMisdreavus
Copy link
Member

I agree - if possible, i'd rather not break the search for docs that show up on stable.

@kennytm kennytm added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Nov 27, 2017
@GuillaumeGomez
Copy link
Member Author

Let's move up the priority then.

@bors: p=10

@bors
Copy link
Contributor

bors commented Nov 28, 2017

⌛ Testing commit 0a12198 with merge 3bde5e7...

bors added a commit that referenced this pull request Nov 28, 2017
@bors
Copy link
Contributor

bors commented Nov 28, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: QuietMisdreavus
Pushing 3bde5e7 to master...

@bors bors merged commit 0a12198 into rust-lang:master Nov 28, 2017
@GuillaumeGomez GuillaumeGomez deleted the fix-global-search branch November 28, 2017 16:55
bors added a commit that referenced this pull request Dec 23, 2017
[beta] Doc search backports

This is a backport of #46081, #46175, #46433, and #46672. They all merged cleanly but I haven't tried a build; let's see what Travis says.

These PRs fix pretty annoying issues with doc search and so I think it's important they don't slip to stable, but these PRs have *NOT* been `beta-accepted` yet.

cc @steveklabnik @GuillaumeGomez can you tag the docs team to talk about beta-acceptance?
@alexcrichton
Copy link
Member

Looks like we forgot to backport this to 1.23.0 (sorry about that!) so removing beta tags

@alexcrichton alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jan 10, 2018
@alexcrichton
Copy link
Member

Er sorry looks like this was backported in #46886

@alexcrichton alexcrichton added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Jan 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants