Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: Suggest typo fixes for resolution errors #13477
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.
changed the title from
diagnostics: Suggest typo fixes for resolution errors
cmd/compile: Suggest typo fixes for resolution errors
Dec 4, 2015
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:
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.
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.