Add levenshtein distance based suggestions everywhere

[Manishearth]

Currently, we suggest typo fixes in case of function calls, locals, and field accesses. So, both the marked lines below will suggest the correct fix:

struct A {foo: u8}
fn main() {
    let x = A {foo: 1};
    x.fob; // here
    let aaaaaaa=1;
    let z = aaaaaab; // here
}

However, this is not the case for imports, crates, and inline paths. We should fix this.

This is probably not an easy bug, but should be fun. Basically you need to look for the source of the "could not find X" error, and do something similar to

rust/src/librustc_resolve/lib.rs

Line 3625 in 99925fb

fn find_best_match_for_name(&mut self, name: &str) -> SuggestionType {

@apasel422 @wafflespeanut want to work on this?

[wafflespeanut]

@Manishearth Thanks, I'll try :)

[Manishearth]

Go ahead!

[mitaa]

I was surprised that I didn't get a suggestion here

fn main() {
    "".is_emtpy();
}

[wafflespeanut]

What could one possibly suggest there? :)

[mitaa]

is_empty? (p and t are flipped)

[wafflespeanut]

Hmm, looks like we currently show suggestions only for the stuff that exist in the source file.

[Manishearth]

No, we just don't handle methods.

[cramertj]

Did crate and inline path support ever get added for this? If not, I'd be interested in giving it a shot.

[Manishearth]

I don't think so. Go ahead!

[nikhilshagri]

@Manishearth can I pick this up if nobody else is working on it?

[Manishearth]

Sure!

[nagisa]

We do not make suggestions for fields behind a reference:

struct Ty { field: () }

fn test1(t: Ty) { t.fied }
fn test2(t: &mut Ty) { t.fied }

error: attempted access of field `fied` on type `Ty`, but no field with that name was found
 --> <anon>:3:19
  |
3 | fn test1(t: Ty) { t.fied }
  |                   ^^^^^^
  |
help: did you mean `field`?
 --> <anon>:3:21
  |
3 | fn test1(t: Ty) { t.fied }
  |                     ^^^^

error: attempted access of field `fied` on type `&mut Ty`, but no field with that name was found
 --> <anon>:4:24
  |
4 | fn test2(t: &mut Ty) { t.fied }
  |                        ^^^^^^

[leonardo-m]

From Issue #38166. Some ideas from: https://gcc.gnu.org/gcc-7/changes.html

const MAX_ITEM: usize = 10;
fn foo_bar() {}
fn foo(c: esize) {} // Misspelled type name.
enum Bar { First, Second }
fn main() {
    let v = [0u32; MAXITEM]; // Misspelled constant name.
    foobar(); // Misspelled function name.
    let b: Bar = Bar::second; // Misspelled enum variant.
}

In all four cases I'd like the Rust compiler to suggest the closest names (usize/isize, MAX_ITEM, foo_bar, Bar::Second).

[petrochenkov]

#38154 uses Levenshtein-based suggestions in all path contexts, but there are two more serious problems:

• candidate set for names in lexical scope (name) is very poor, it includes only local variables and type parameters ("bindings in ribs"), it needs to include items as well. (fixed in resolve: Levenshtein-based suggestions for non-import paths #38927)
• candidate set for names in some module's scope (a::b::name) is not built at all, so these names don't get suggestions. (fixed in resolve: Levenshtein-based suggestions for non-import paths #38927)

[petrochenkov]

Suggestions for last segments of non-import paths are implemented in #38927

Remaining items:

• Segments in path prefixes.
• Segments in import paths.
• Extern crates (what is the source of suggestions, command line?). - not that useful these days so can be skipped
• Lifetime names.
• Label names (Add suggestions for misspelled labels #45173).
• Macro names in #[macro_use].
• Macro names in #[derive] (Refactor macro resolution errors + add derive macro suggestions #39752).
  • Include use imports.
• Improvements to fields? (Add levenshtein distance based suggestions everywhere #30197 (comment))
• Method calls (Add suggestions for misspelled method names #44297).

[laumann]

Hi! Is anyone working on adding suggestions for method names (re @mitaa's is_emtpy() example)? I have a patch that I wrote some time ago that implements this, but if someone else is working on it I don't want to get in the way.

[laumann]

If @petrochenkov's list is being kept up-to-date, I think the "method calls" point can be crossed off.

[petrochenkov]

@laumann
Updated the list.
Thanks for working on this.

[laumann]

@petrochenkov Happy to help :-)

I considered looking into suggestions for "Lifetime and label names" next - that sounds like it should be more or less straight-forward...

[petrochenkov]

@laumann
It should be straightforward, but note that with #44524 typos in lifetimes will be impossible by definition (every typo becomes a new lifetime, modulo some corner cases).

[steveklabnik]

Triage: do we plan on doing more of this? I'm not sure.