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.