|syntax errors firstname.lastname@example.org (1995-02-20)|
|Re: syntax errors email@example.com (1995-02-22)|
|Re: syntax errors firstname.lastname@example.org (1995-02-23)|
|Re: syntax errors email@example.com (1995-02-27)|
|Re: syntax errors firstname.lastname@example.org (1995-02-28)|
|From:||email@example.com (Mike Lee)|
|Date:||Tue, 28 Feb 1995 03:17:32 GMT|
In comp.compilers, firstname.lastname@example.org (Mike McCarty) writes:
| <email@example.com> wrote:
| )Hello. Could anyone point me to work done on locating (and presenting)
| )syntax errors? ...
| 1. The precise location in the source where the error was
| detected. [...]
| 2. The severity of the error
| 3. An indication of the nature of the error
| 4. What fixup/action was taken to recover from the error
| Examples of acceptable error reports:
| x = 2*(3+4;
| Error: Expected ')' in expression, object generation suppressed.
I agree fully with 1 through 4 and would like to amplify on 1.
A parser I was implementing (using y&l) for a language to be used via a
GUI "obviously" needed to position the cursor at the source of the
error. Simple syntax errors were pretty easy to point out; I had only
the lookahead to deal with.
All of the semantic checking was done after lex and yacc had finished
their jobs (most of which involved traversing up and down and across
the parse tree). I had dutifully placed line numbers and character
positions on the tokens so that the cursor could be positioned. But I
got some complaints from users that it would be nice not merely
position the cursor, but to use the GUI text selection to highlight the
whole of the error, e.g. the entire undeclared identifier, or the whole
misplaced statement. To implement this, I did a quick extra pass to
propagate starting and ending positions up the parse tree. Each
non-terminal was assigned the starting position of the earliest
terminal below it and the ending position of the last.
Anyway, when an error occurred, I simply grabbed the positions from the
most relevant node in the tree that for that error and passed the
positions off to the GUI editor.
With this kind of information you can do stuff like this (highlighting
shown with caret symbols):
void foo(char *, int);
void bar(float, int);
foo("thingy", bar(5.0, 91));
"Error in fred.c: void expression cannot be used as parameter."
which I feel is significantly easier for the reader to grasp than
placing the cursor (or caret, for a text-oriented error report) between
the two right parentheses.
Return to the
Search the comp.compilers archives again.