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

Suggest a case insensitive match name regardless of levenshtein distance #89956

Merged

Conversation

JohnTitor
Copy link
Member

Fixes #86170

Currently, find_best_match_for_name only returns a case insensitive match name depending on a Levenshtein distance. It's a bit unfortunate that that hides some suggestions for typos like Bar -> BAR. That idea is from #46347 (comment), but I think it still makes some sense to show a candidate when we find a case insensitive match name as it's more like a typo.
Skipped the candidate != lookup check because the current (i.e, levenshtein_match) returns the exact same Symbol anyway but it doesn't seem to confuse anything on UI tests.

r? @estebank

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 16, 2021
@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Oct 18, 2021

📌 Commit d4cc877 has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 18, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 18, 2021
…match-names, r=estebank

Suggest a case insensitive match name regardless of levenshtein distance

Fixes rust-lang#86170

Currently, `find_best_match_for_name` only returns a case insensitive match name depending on a Levenshtein distance. It's a bit unfortunate that that hides some suggestions for typos like `Bar` -> `BAR`. That idea is from rust-lang#46347 (comment), but I think it still makes some sense to show a candidate when we find a case insensitive match name as it's more like a typo.
Skipped the `candidate != lookup` check because the current (i.e, `levenshtein_match`) returns the exact same `Symbol` anyway but it doesn't seem to confuse anything on UI tests.

r? `@estebank`
This was referenced Oct 18, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 19, 2021
…askrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#89766 (RustWrapper: adapt for an LLVM API change)
 - rust-lang#89867 (Fix macro_rules! duplication when reexported in the same module)
 - rust-lang#89941 (removing TLS support in x86_64-unknown-none-hermitkernel)
 - rust-lang#89956 (Suggest a case insensitive match name regardless of levenshtein distance)
 - rust-lang#89988 (Do not promote values with const drop that need to be dropped)
 - rust-lang#89997 (Add test for issue rust-lang#84957 - `str.as_bytes()` in a `const` expression)
 - rust-lang#90002 (:arrow_up: rust-analyzer)
 - rust-lang#90034 (Tiny tweak to Iterator::unzip() doc comment example.)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 8c8835d into rust-lang:master Oct 19, 2021
@rustbot rustbot added this to the 1.58.0 milestone Oct 19, 2021
@JohnTitor JohnTitor deleted the suggest-case-insensitive-match-names branch October 19, 2021 09:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"No item found" diagnostic should suggest items that differ by case
5 participants