Add case insensitive comparison, besides Levenstein for DYM #46347

raventid · 2017-11-28T21:10:27Z

Draft version. The idea is that Levenstein does not work for some cases when we have multiple equal weights for strings. I didn't understand the case with if found != name => Some(found) so it means that new code does not work correctly yet.

At least now I think that we might return all maximal weights from levenstein and think about next cases in priority order:

There is exact match -> None
There is exact match, but case insensitive -> Some(match)
There is some match from levenstein -> Some(matches.take_any)
There is no match -> None

@estebank WDYT?

rust-highfive · 2017-11-28T21:10:41Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

zackmdavis · 2017-11-29T06:04:10Z

src/test/ui/issue46332.rs

@@ -0,0 +1,14 @@
+// Original problem is Levenstein distance.
+
+fn TyUint() {


(An enum variant rather than a function is closer to the spirit of the example in the issue (which isn't to say that we shouldn't test functions, too, but those are snake_case_in_standard_style, unlike TyUint).)

zackmdavis · 2017-11-29T06:07:05Z

src/test/ui/issue46332.rs

@@ -0,0 +1,14 @@
+// Original problem is Levenstein distance.
+


issue-46332.rs (with the hyphen) as a file name would conform more with most of the other test file names. The license also needs to be at the top of the file (the build system will check).

zackmdavis · 2017-11-29T06:16:19Z

src/librustc_resolve/lib.rs

+
+
+        // Ugly code, just to see if using case insensitive comparison will help
+        let exact_match = names.iter().find(|x| x.as_str().to_uppercase() == name.as_str().to_uppercase());


case_insensitive_match would be a less-misleading name.

zackmdavis · 2017-11-29T06:17:31Z

src/librustc_resolve/lib.rs

+                Some(found) => Some(found.clone()),
+                _ => None,
+            }
+        }


Less nesting:

if case_insensitive_match.is_some() { return case_insensitive_match.cloned() }

zackmdavis · 2017-11-29T06:24:16Z

src/librustc_resolve/lib.rs

+                _ => None,
+            }
+        }
+


It occurs to me that we should likely be making this change as a "tiebreaker" in syntax::util::lev_distance::find_best_match_for_name itself: the only time case-insensitive match is going to do better than minimizing Levenshtein distance is when there's a tie for the minimum and the method makes an unlucky choice among the minima, as in the motivating example (TyInt and TyUint are both Levenshtein-distance 1 away from TyUInt).

petrochenkov · 2017-11-29T08:24:17Z

I didn't understand the case with if found != name

It looks very silly when you write foo and compiler tells you "foo is wrong, use foo instead".
The candidate search isn't precise so it can sometimes find things that have the same name (perfect match from Levenshtein's distance point of view!) but are still inaccessible, so we need to filter them away.

estebank

Agree with the comments above.

estebank · 2017-11-29T16:33:01Z

src/librustc_resolve/lib.rs

+                Some(found) => Some(found.clone()),
+                _ => None,
+            }
+        }


This code can be written as

if let Some(found) = exact_match { return Some(found.clone()); }

estebank · 2017-11-29T16:36:23Z

src/librustc_resolve/lib.rs

+
+
+        // Ugly code, just to see if using case insensitive comparison will help
+        let exact_match = names.iter().find(|x| x.as_str().to_uppercase() == name.as_str().to_uppercase());


This should be the following to account for @petrochenkov's comment

names.iter().find(|x| { x.as_str().to_uppercase() == name.as_str().to_uppercase() && x.as_str() != name.as_str() })

estebank · 2017-11-29T16:37:35Z

src/test/ui/issue46332.rs

+
+fn main() {
+    TyUInt();
+}


You're missing the .stderr file in this PR.

estebank · 2017-11-30T23:26:59Z

src/test/ui/issue-46332.rs

+struct TyInt {}
+
+fn main() {
+    TyUInt {};


You need to add a comment below this to test for errors that do not care for the ui output:

//~^ ERROR cannot find struct, variant or union type `TyUInt` in this scope

The lack of this is why the test failed. It was made mandatory recently.

Thank you! Fixed the build.

estebank · 2017-12-01T18:03:18Z

@bors r+

bors · 2017-12-01T18:03:19Z

📌 Commit f18446e has been approved by estebank

petrochenkov · 2017-12-01T22:13:18Z

An alternative would be to adjust the distance formula to incorporate case differences, e.g. insertion/deletion/arbitrary substitution would still add 1 to the distance, but different case substitution would add 0.5.

bors · 2017-12-02T12:43:00Z

⌛ Testing commit f18446e with merge 7a64987...

@estebank

…ebank Add case insensitive comparison, besides Levenstein for DYM Closes #46332 Draft version. The idea is that Levenstein does not work for some cases when we have multiple equal weights for strings. I didn't understand the case with `if found != name => Some(found)` so it means that new code does not work correctly yet. At least now I think that we might return all maximal weights from levenstein and think about next cases in priority order: 1) There is exact match -> None 2) There is exact match, but case insensitive -> Some(match) 3) There is some match from levenstein -> Some(matches.take_any) 4) There is no match -> None @estebank WDYT?

bors · 2017-12-02T15:08:04Z

☀️ Test successful - status-appveyor, status-travis
Approved by: estebank
Pushing 7a64987 to master...

…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`

…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``

Add case insensitive comparison, besides Levenstein

6506f9c

rust-highfive assigned pnkfelix Nov 28, 2017

zackmdavis reviewed Nov 29, 2017

View reviewed changes

kennytm added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Nov 29, 2017

estebank reviewed Nov 29, 2017

View reviewed changes

move comparator into +find_best_match_name+ function

537f2a6

estebank reviewed Nov 30, 2017

View reviewed changes

add magic comment for ui test, remove newline

f18446e

raventid changed the title ~~WIP: Add case insensitive comparison, besides Levenstein for DYM~~ Add case insensitive comparison, besides Levenstein for DYM Dec 1, 2017

bors merged commit f18446e into rust-lang:master Dec 2, 2017

ben0x539 mentioned this pull request Jun 16, 2021

"No item found" diagnostic should suggest items that differ by case #86170

Closed

JohnTitor mentioned this pull request Oct 16, 2021

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

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add case insensitive comparison, besides Levenstein for DYM #46347

Add case insensitive comparison, besides Levenstein for DYM #46347

raventid commented Nov 28, 2017

rust-highfive commented Nov 28, 2017

zackmdavis Nov 29, 2017

zackmdavis Nov 29, 2017

zackmdavis Nov 29, 2017

zackmdavis Nov 29, 2017

zackmdavis Nov 29, 2017

petrochenkov commented Nov 29, 2017

estebank left a comment

estebank Nov 29, 2017

estebank Nov 29, 2017

estebank Nov 29, 2017

estebank Nov 30, 2017

raventid Dec 1, 2017

estebank commented Dec 1, 2017

bors commented Dec 1, 2017

petrochenkov commented Dec 1, 2017

bors commented Dec 2, 2017

bors commented Dec 2, 2017

		@@ -0,0 +1,14 @@
		// Original problem is Levenstein distance.

		fn TyUint() {



		// Ugly code, just to see if using case insensitive comparison will help
		let exact_match = names.iter().find(\|x\| x.as_str().to_uppercase() == name.as_str().to_uppercase());

Add case insensitive comparison, besides Levenstein for DYM #46347

Add case insensitive comparison, besides Levenstein for DYM #46347

Conversation

raventid commented Nov 28, 2017

rust-highfive commented Nov 28, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov commented Nov 29, 2017

estebank left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

estebank commented Dec 1, 2017

bors commented Dec 1, 2017

petrochenkov commented Dec 1, 2017

bors commented Dec 2, 2017

bors commented Dec 2, 2017