This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2
- From: Michael Matz <matz at suse dot de>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: David Malcolm <dmalcolm at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Manuel López-Ibáñez <lopezibanez at gmail dot com>
- Date: Wed, 16 Sep 2015 15:22:21 +0200 (CEST)
- Subject: Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2
- Authentication-results: sourceware.org; auth=none
- References: <55F2F393 dot 9050501 at gmail dot com> <1442331491-11471-1-git-send-email-dmalcolm at redhat dot com> <CAFiYyc27FUtEgdPfohvtxQtLywBzKWUe9pYC0BJR7cJJxYL+qw at mail dot gmail dot com>
Hi,
On Wed, 16 Sep 2015, Richard Biener wrote:
> Btw, this looks quite expensive - I'm sure we want to limit the effort
> here a bit.
I'm not so sure. It's only used for printing an error, so walking all
available decls is expensive but IMHO not too much so.
> I don't want us to suggest using 'i' instead of j (a good hint is that I
> used 'j' multiple times).
Well, there will always be cases where the suggestion is actually wrong.
How do you propose to deal with this? The above case could be solved by
not giving hints when the levenshtein distance is as long as the string
length (which makes sense, because then there's no relation at all between
the string and the suggestion).
> So while the idea might be an improvement to selected cases it can cause
> confusion as well. And if using the suggestion for further parsing it
> can cause worse followup errors (unless we can limit such "fixup" use to
> the cases where we can parse the result without errors). Consider
>
> foo()
> {
> foz = 1;
> }
>
> if we suggest 'foo' instead of foz then we'll get a more confusing followup
> error if we actually use it.
This particular case could be solved by ruling out candidaten of the wrong
kind (here, something that can be assigned to, vs. a function). But it
might actually be too early in parsing to say that there will be an
assignment. I don't think _this_ problem should block the patch.
Ciao,
Michael.