On Wed, Sep 16, 2015 at 3:22 PM, Michael Matz <m...@suse.de> wrote:
> 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.
Well, as we're not stopping at the very first error creating an
artificial testcase
that hits this quite badly should be possible. Maybe only try this for
the first error and not for followups?
>> 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.
I wonder if we can tentatively parse with the choice at hand, only allowing
(and even suggesting?) it if that works out.
Richard.
>
> Ciao,
> Michael.
