public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: "Manuel López-Ibáñez" <lopezibanez@gmail.com>
Cc: Michael Matz <matz@suse.de>, David Malcolm <dmalcolm@redhat.com>,
		GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2
Date: Thu, 17 Sep 2015 08:46:00 -0000	[thread overview]
Message-ID: <CAFiYyc3yV1YMSXvOXZGJRWEUptyfRM3FKoDvCwYuwOQzBm-afg@mail.gmail.com> (raw)
In-Reply-To: <CAESRpQA3SSUeG1L9KYNE0vjjqQhea31uJAePptTLseqwv1VqnQ@mail.gmail.com>

On Wed, Sep 16, 2015 at 5:45 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 16 September 2015 at 15:33, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Wed, Sep 16, 2015 at 3:22 PM, Michael Matz <matz@suse.de> wrote:
>>>> 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.
>
> Indeed. The patch by David does not try to fix-up the code, it merely
> suggests a possible candidate. The follow-up errors should be the same
> before and after. Such suggestions will never be 100% right, even if
> the suggestion makes the code compile and run, it may still be the
> wrong one. A wrong suggestion is far less serious than a wrong
> uninitialized or Warray-bounds warning and we can live with those. Why
> this needs to be perfect from the very beginning?
>
> BTW, there is a PR for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52277
>
>> I wonder if we can tentatively parse with the choice at hand, only allowing
>> (and even suggesting?) it if that works out.
>
> This would require to queue the error, fix-up the wrong name and
> continue parsing. If there is another error, ignore that one and emit
> the original error without suggestion. The problem here is that we do
> not know if the additional error is actually caused by the fix-up we
> did or it is an already existing error. It would be equally terrible
> to emit errors caused by the fix-up or emit just a single error for
> the typo. We would need to roll-back the tentative parse and do a
> definitive parse anyway. This does not seem possible at the moment
> because the parsers maintain a lot of global state that is not easy to
> roll-back. We cannot simply create a copy of the parser state and
> throw it away later to continue as if the tentative parse has not
> happened.
>
> I'm not even sure if, in general, one can stop at the statement level
> or we would need to parse the whole function (or translation unit) to
> be able to tell if the suggestion is a valid candidate.

I was suggesting to only tentatively finish parsing the "current construct".
No idea how to best figure that out to the extend to make the tentative
parse useful.  Say, if we have "a + s.foz" and the field foz is not there
but foo is, so if we continue parsing with 'foo' instead but 'foo' will have
a type that makes "a + s.foo" invalid then we probably shouldn't suggest
it.  It _might_ be reasonably "easy" to implement that, but I'm not sure.
There might be a field named fz (with same or bigger levenstein distance)
with the correct type.  Of course it might have been I misspelled
's' and meant 'r' instead which has a field foz of corect type... (and 's'
is available as well).

I agree that we don't have to solve all this in the first iteration.

Richard.

> Cheers,
>
> Manuel.

  reply	other threads:[~2015-09-17  8:43 UTC|newest]

Thread overview: 133+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-10 20:12 [PATCH 00/22] RFC: Overhaul of diagnostics David Malcolm
2015-09-10 20:12 ` [PATCH 01/22] Change of location_get_source_line signature David Malcolm
2015-09-14 19:28   ` Jeff Law
2015-09-15 17:02     ` David Malcolm
2015-09-10 20:13 ` [PATCH 08/22] C frontend: use token ranges in various diagnostics David Malcolm
2015-09-10 20:13 ` [PATCH 02/22] Testsuite: add dg-{begin|end}-multiline-output commands David Malcolm
2015-09-14 19:35   ` Jeff Law
2015-09-14 22:17     ` Bernhard Reutner-Fischer
2015-09-14 22:45       ` Jeff Law
2015-09-15 17:53         ` dejagnu version update? Mike Stump
2015-09-15 19:23           ` David Malcolm
2015-09-15 20:29             ` Jeff Law
2015-09-15 21:15               ` Bernhard Reutner-Fischer
2017-05-13 10:38                 ` Bernhard Reutner-Fischer
2017-05-13 11:06                   ` Jakub Jelinek
2017-05-13 21:12                     ` Jeff Law
2017-05-14 23:10                       ` NightStrike
2017-05-15  8:14                         ` Richard Biener
2017-05-15 19:24                           ` Mike Stump
2017-05-15 20:52                             ` Andreas Schwab
2017-05-16  9:56                     ` Jonathan Wakely
2017-05-16 12:16                       ` Bernhard Reutner-Fischer
2017-05-16 12:35                         ` Jonathan Wakely
2017-05-16 12:55                           ` Bernhard Reutner-Fischer
2017-05-16 18:41                             ` Matthias Klose
2017-05-16 19:09                           ` Mike Stump
2018-08-04 16:32                             ` Bernhard Reutner-Fischer
2018-08-06 14:33                               ` Jonathan Wakely
2018-08-06 15:26                               ` Mike Stump
2018-08-07 16:34                                 ` Segher Boessenkool
2018-08-08 11:18                                   ` Bernhard Reutner-Fischer
2018-08-08 13:35                                     ` Richard Earnshaw (lists)
2018-08-08 14:37                                     ` Michael Matz
2018-08-08 16:45                                     ` Segher Boessenkool
2021-10-27 23:00                               ` Bernhard Reutner-Fischer
2021-10-28 19:11                                 ` Jeff Law
2021-10-29  0:41                                   ` [PATCH] Bump required minimum DejaGnu version to 1.5.3 Bernhard Reutner-Fischer
2021-10-29  7:32                                     ` Richard Biener
2021-11-04 11:55                                       ` Segher Boessenkool
2021-11-04 12:22                                         ` Martin Liška
2021-11-04 19:09                                           ` Segher Boessenkool
2021-11-05  9:33                                             ` Richard Biener
2021-11-05 11:39                                               ` Jonathan Wakely
2021-11-04 12:41                                         ` Richard Biener
2021-11-04 13:50                                           ` Jonathan Wakely
2015-09-15 19:53           ` dejagnu version update? Bernhard Reutner-Fischer
2015-09-15 20:05             ` Jeff Law
2015-09-15 23:12               ` Mike Stump
2015-09-16  7:41                 ` Andreas Schwab
2015-09-16 16:19                   ` Mike Stump
2015-09-16 16:32                     ` Ramana Radhakrishnan
2015-09-16 16:39                       ` Jeff Law
2015-09-16 17:26                         ` Trevor Saunders
2015-09-16 17:46                         ` David Malcolm
2015-09-16 19:09                           ` Bernhard Reutner-Fischer
2015-09-16 19:51                             ` Mike Stump
2015-09-17  0:07                           ` Segher Boessenkool
2015-09-17 13:57                         ` Richard Earnshaw
2015-09-16 18:04                       ` Mike Stump
2015-09-16 18:58                         ` Bernhard Reutner-Fischer
2015-09-16 19:37                         ` Ramana Radhakrishnan
2015-09-16 13:17             ` Matthias Klose
2015-09-16 15:46               ` Bernhard Reutner-Fischer
2015-09-10 20:13 ` [PATCH 10/22] C++ FE: Use token ranges for various diagnostics David Malcolm
2015-09-10 20:13 ` [PATCH 06/22] PR/62314: add ability to add fixit-hints David Malcolm
2015-09-10 20:13 ` [PATCH 03/22] Move diagnostic_show_locus and friends out into a new source file David Malcolm
2015-09-14 19:37   ` Jeff Law
2015-09-18 18:31     ` David Malcolm
2015-09-10 20:13 ` [PATCH 13/22] gcc-rich-location.[ch]: add methods for working with tree ranges David Malcolm
2015-09-10 20:13 ` [PATCH 20/22] Use rich locations in c-family/c-format.c David Malcolm
2015-09-10 20:13 ` [PATCH 11/22] Objective C: c/c-parser.c: use token ranges in two places David Malcolm
2015-09-10 20:13 ` [PATCH 09/22] C frontend: store and use token ranges in c_declspecs David Malcolm
2015-09-10 20:28 ` [PATCH 07/22] Implement token range tracking within libcpp and C/C++ FEs David Malcolm
2015-09-11 14:08   ` Michael Matz
2015-09-14 19:41     ` Jeff Law
2015-09-15 10:20   ` Richard Biener
2015-09-15 10:28     ` Jakub Jelinek
2015-09-15 10:48       ` Richard Biener
2015-09-15 11:01         ` Jakub Jelinek
2015-09-16 20:29           ` David Malcolm
2015-09-17 16:54             ` David Malcolm
2015-09-17 19:15               ` Jeff Law
2015-09-17 20:06                 ` David Malcolm
2015-09-17 19:25         ` Jeff Law
2015-09-15 12:09       ` Manuel López-Ibáñez
2015-09-15 12:18         ` Richard Biener
2015-09-15 12:57           ` Manuel López-Ibáñez
2015-09-17 19:11             ` Jeff Law
2015-09-17 19:13           ` Jeff Law
2015-09-15 13:53       ` David Malcolm
2015-09-10 20:29 ` [PATCH 05/22] Add overloads of inform, warning_at, etc that take a source_range David Malcolm
2015-09-10 20:29 ` [PATCH 04/22] Reimplement diagnostic_show_locus, introducing rich_location classes David Malcolm
2015-09-11 13:44   ` Michael Matz
2015-09-11 14:12   ` Michael Matz
2015-09-11 15:15     ` David Malcolm
2015-09-10 20:30 ` [PATCH 12/22] Add source-ranges for trees David Malcolm
2015-09-10 20:30 ` [PATCH 15/22] Add plugin to recursively dump the source-ranges in a tree David Malcolm
2015-09-11  3:19   ` Martin Sebor
2015-09-10 20:30 ` [PATCH 14/22] C: capture tree ranges for various expressions David Malcolm
2015-09-10 20:31 ` [PATCH 18/22] Track locations within string literals in tree_string David Malcolm
2015-09-10 20:31 ` [PATCH 19/22] gcc-rich-location.[ch]: add debug methods for cpp_string_location David Malcolm
2015-09-10 20:32 ` [PATCH 17/22] libcpp: add location tracking within string literals David Malcolm
2015-09-10 20:32 ` [PATCH 16/22] C/C++ frontend: use tree ranges in various diagnostics David Malcolm
2015-09-10 20:32 ` [PATCH 21/22] Use Levenshtein distance for various misspellings in C frontend David Malcolm
2015-09-10 21:11   ` Andi Kleen
2015-09-11 15:31   ` Manuel López-Ibáñez
2015-09-15 15:25     ` [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2 David Malcolm
2015-09-15 16:25       ` Manuel López-Ibáñez
2015-09-16  8:45       ` Richard Biener
2015-09-16 13:33         ` Michael Matz
2015-09-16 14:00           ` Richard Biener
2015-09-16 15:49             ` Manuel López-Ibáñez
2015-09-17  8:46               ` Richard Biener [this message]
2015-09-17 19:32         ` Jeff Law
2015-09-17 20:05           ` David Malcolm
2015-09-17 20:52             ` Manuel López-Ibáñez
2015-10-30 12:30           ` [PATCH 0/2] Levenshtein-based suggestions (v3) David Malcolm
2015-10-30 12:30             ` [PATCH 2/2] C FE: suggest corrections for misspelled field names David Malcolm
2015-10-30 12:36             ` [PATCH 1/2] Implement Levenshtein distance David Malcolm
2015-11-02 10:56               ` Mikael Morin
2015-11-02  6:44             ` [PATCH 0/2] Levenshtein-based suggestions (v3) Jeff Law
2015-11-13  2:08               ` David Malcolm
2015-11-13  6:57                 ` Marek Polacek
2015-11-13 12:16                   ` David Malcolm
2015-11-13 15:11                     ` Marek Polacek
2015-11-13 15:44                       ` Bernd Schmidt
2015-11-13 15:53                         ` Marek Polacek
2015-11-13 15:56                           ` Jakub Jelinek
2015-11-13 16:02                             ` Marek Polacek
2015-09-10 20:50 ` [PATCH 22/22] Add fixit hints to spellchecker suggestions David Malcolm
2015-09-14 17:49 ` [PATCH 00/22] RFC: Overhaul of diagnostics Bernd Schmidt
2015-09-14 19:44   ` Jeff Law
2015-09-15  1:11     ` David Malcolm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc3yV1YMSXvOXZGJRWEUptyfRM3FKoDvCwYuwOQzBm-afg@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=lopezibanez@gmail.com \
    --cc=matz@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).