From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36170 invoked by alias); 16 Sep 2015 13:33:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 36155 invoked by uid 89); 16 Sep 2015 13:33:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f174.google.com Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 16 Sep 2015 13:33:09 +0000 Received: by ykdg206 with SMTP id g206so218422243ykd.1 for ; Wed, 16 Sep 2015 06:33:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.81.5 with SMTP id x5mr28267550ykx.82.1442410387235; Wed, 16 Sep 2015 06:33:07 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Wed, 16 Sep 2015 06:33:07 -0700 (PDT) In-Reply-To: References: <55F2F393.9050501@gmail.com> <1442331491-11471-1-git-send-email-dmalcolm@redhat.com> Date: Wed, 16 Sep 2015 14:00:00 -0000 Message-ID: Subject: Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2 From: Richard Biener To: Michael Matz Cc: David Malcolm , GCC Patches , =?UTF-8?B?TWFudWVsIEzDs3Blei1JYsOhw7Fleg==?= Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01180.txt.bz2 On Wed, Sep 16, 2015 at 3:22 PM, Michael Matz 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.