Related articles |
---|
Yacc error recovery... kaz@nt.com (1996-10-03) |
Re: Yacc error recovery... miano@worldnet.att.net (1996-10-06) |
Re: Yacc error recovery... itz@rahul.net (1996-10-12) |
Re: Yacc error recovery... creedy@mitretek.org (1996-10-24) |
From: | creedy@mitretek.org (Chris Reedy) |
Newsgroups: | comp.compilers |
Date: | 24 Oct 1996 22:38:41 -0400 |
Organization: | Mitretek Systems |
References: | 96-10-011 96-10-036 |
Keywords: | parse, yacc, errors |
itz@rahul.net (Ian T Zimmerman) wrote:
> TOPLAS vol.17 No.4 (July 95) pp. 672 and forward describes adding a
> fully automated error method to Bison. The article together with
> relevant source code are available on
>
> http://www.cosc.canterbury.ac.nz/~bruce
How would the technique in the article handle the following (ANSI/C) error?
int a_function( int p1, foo p2, int p3) {
/* something involving p1, p2, and p3 */
}
foo was supposed to be int but I mistyped (when it actually happened
to me it came out Int -- can you tell the difference on your display?
I couldn't). The compiler I was using at the time reduced foo as a
parameter name, produced the unhelpful error message "syntax error",
and discarded "p2, int p3". It then produced additional errors in the
body for unknown variables p2 and p3.
I read the article and it seemed to me that the article would produce
something similar to the above, since the error token is "p2" while
the actual error was in "foo". If I'm right, are there error recovery
techniques that will recover by recognizing that foo was supposed to
be a type name?
Chris
Dr. Christopher L. Reedy, Mail Stop Z667
Mitretek Systems, 7525 Colshire Drive, McLean, VA 22102-7400
Email: creedy@mitretek.org Phone: (703) 610-1615 FAX: (703) 610-1603
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.