Re: new parser: error recovery needs work

[Jeff Donner <jdonner at cs dot nmsu dot edu>]

<a href="http://gcc.gnu.org/ml/gcc/2003-01/msg00663.html";>Re:</a>

>--On Monday, January 13, 2003 03:46:43 PM -0800 Joe Buck 
><jbuck@synopsys.com> wrote:
>
> The new parser doesn't produce useful diagnostics in the presence of
> common errors.  Since the old parser did better, this is a regression.
>
>-- Mark Mitchell:
>To be honest, I'm somewhat unsympathetic.  Not because I think the >error
>messages are good, or because I think that we shouldn't do better, but
>because it's hard to do better in some of these cases and because
>we do noticably better in other cases -- the old parser just said
>"parse error" a lot. :-)
>
>It's also hard to do better without breaking legal programs; it takes
>a lot of head-scratching to think of all the cases.
>
>> The new parser might want to use a strategy that goes something
>> like this:
>> make a guess as to what was intended.  If a complete statement can be
>> parsed according to that guess, then keep it.  Optionally try a >second
>> guess, if there is one available, otherwise skip to some >synchronizing
>> token.
>
>-- Mark Mitchell:
>I'd prefer that we not introduce yet more backtracking.  Too >complicated.
>...

If there is an explicit trace of states / previously seen tokens,
you can use it to dispense with having to imagine errors
by having a bunch of programmers dump traces when
they make errors.  A human analyses these, and maps
the traces to nice human messages.  (This idea comes from
a tool that automates this process for YACC-based compilers,

http://unicon.sourceforge.net/merr

which has a paper that explains the idea.)  This makes it
mechanical instead of imagination-stressing to deal with
the many specific cases, & it turns out it has pretty good
resolving power.

Examples of what a token trace can distinguish,
  allowing specific messages:
int main()       // parenthesis or semi-colon expected
int x y;         // missing comma in variable list
char() {}        // function name expected
int a[] = {1, 2; // unclosed initializer
struct foo
int x;           // missing { after struct label

So, I'm saying if it isn't in there, such a
state/token-trace & dump facility would make
constructing the error messages more mechanical, and
take less expertise to find/add new ones, and allow
a more comprehensive & specific set of messages.

Jeff Donner