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

cmd/compile: Suggest typo fixes for resolution errors #13477

Open
Manishearth opened this Issue Dec 4, 2015 · 9 comments

Comments

Projects
None yet
5 participants
@Manishearth
Contributor

Manishearth commented Dec 4, 2015

In case of "cannot find package" or "undefined" errors, perhaps we should suggest typo fix solutions?

The basic idea is to look for all allowed names in that position with the minimum levenshtein distance (perhaps capping it at 3 or something), and suggest those.

Rust does this and it's pretty useful.

@Manishearth

This comment has been minimized.

Contributor

Manishearth commented Dec 4, 2015

(willing to work on part of this if it's a change wanted by the Go community)

@ianlancetaylor ianlancetaylor changed the title from diagnostics: Suggest typo fixes for resolution errors to cmd/compile: Suggest typo fixes for resolution errors Dec 4, 2015

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Dec 4, 2015

@odeke-em

This comment has been minimized.

Member

odeke-em commented Jan 14, 2017

@Manishearth I haven't seen any objections to it here so far, IMO it would a nice to have. Please let me know if you'd still like to work on it or I can take over and get it in for Go1.9.
Thanks.

@Manishearth

This comment has been minimized.

Contributor

Manishearth commented Jan 14, 2017

Feel free to take over, I don't have much time right now 😄

@odeke-em

This comment has been minimized.

Member

odeke-em commented Jan 14, 2017

Sounds Gucci To Me, thanks!

@odeke-em

This comment has been minimized.

Member

odeke-em commented Jan 19, 2017

@gopherbot

This comment has been minimized.

gopherbot commented Jan 23, 2017

CL https://golang.org/cl/35471 mentions this issue.

@rsc

This comment has been minimized.

Contributor

rsc commented Jan 30, 2017

Replied on CL:

Please do not do this with only edit distance. This can lead to comically bad suggestions. The suggestion should only be made if it actually fits in the surrounding code. For example, if the suggestion would cause type errors, it's a bad suggestion and should not be made. It's not clear to me the compiler is set up for that kind of analysis, in which case the suggestions should simply not be made.

One of the things I strongly dislike about clang is its nonsensical suggestions. There needs to be a prior probability assigned to "maybe the thing really is undefined" instead of trying to match it to something that is defined. I got this once, which illustrates the problem with edit distance nicely:

use of undeclared identifier 'deadline_'; did you mean 'readlink'?

No, even though the edit distance is small, no one types deadline_ instead of readlink. No one. Edit distance clearly doesn't capture the typos people actually make.

If we're going to make further changes to suggestions, I would like to see actual data about the kinds of mistakes people make first.

/cc @dr2chase

@odeke-em

This comment has been minimized.

Member

odeke-em commented Jan 31, 2017

That's a great point @rsc. While experimenting offline, I noticed the same problem, comically bad suggestions also present in the CL test/fixedbugs/*.go file e.g TOOOOOOOOL -> did you mean Id?.
For sure, I look forward to hearing from @dr2chase and other folks.

@Manishearth

This comment has been minimized.

Contributor

Manishearth commented Jan 31, 2017

TOOOOOOOOL -> did you mean Id?

You need to have a limit on the distance for this to work.


FWIW rustc just uses edit distance with a bound and the suggestions are pretty good. It does no type analysis. Yes, it has its flaws with things like deadline/readlink, but it seems to work pretty ok. I find such cases pretty rare.

The heuristics we use are:

Of course the languages are different enough that these heuristics may not be general.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment