Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6949 > unrolled thread

Re: Parsing and reporting errors?

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Parsing and reporting errors? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 15:59 +0100
    Re: Parsing and reporting errors? Robert Wessel <robertwessel2@yahoo.com> - 2016-09-30 17:45 -0500

#6949 — Re: Parsing and reporting errors?

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   A parser (syntactical analyser) gets tokens from the scanner
>   (lexical analyser), which gets characters from a character source.
>   (In terms of OOP, each of these, the parser, the scanner and
>   the character source might be an individual object.)
>
>   It might happen that the parser detects a syntax error.
>   How can it then report this?
>
>   Ok, it might print the token and a diagnostic message.
>
>   But the parser does not know the line and the offset in the
>   line, so it can't print the line number and source context.
>   This has already been abstracted away by the lower entities
>   (the scanner and the character source). Usually, the parser
>   does not need to know these lower-level details.
>
>   How does one usually deal with this? (Printing the line number,
>   the line offset and the region of the source code where the
>   error was detected when the parser detects an error)
>
>   My first idea was to decorate each and every token with
>   such context information that can be used in the case
>   of an error, so that the parser then can access it.

This is what I would do.  And I'd be prepared to store quite a lot
information.  gcc can relate a token back to the macro expansion that
gave rise it, for example.

>   So, when the parser detects an erroneous token,
>   it would get the line number and line offset of the token
>   from this token itself and then incorporate it in the error
>   message.
>
>   Another idea was that the parser can "pass down"
>   a call to the scanner to ask it to print an error
>   message adding the context (which the scanner in
>   turn might pass down to the character source).

The trouble with this is that you may come across errors very much later
in the process (even after the complete parse) where it would be helpful
to refer to the source.

>   So, in this case, when the parser would detect an
>   erroneous token, it would ask the scanner to print
>   a message indicating the "current position" 
>   (line number and line offset) of the scanner.
>
>   However, due to "lookahead" or some "buffering",
>   the current position of the scanner might already
>   be ahead of that current token of the parser.

Quite, but this is only a simple example of what can go wrong.

-- 
Ben.

[toc] | [next] | [standalone]

#6956

On Fri, 30 Sep 2016 15:59:00 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>>   A parser (syntactical analyser) gets tokens from the scanner
>>   (lexical analyser), which gets characters from a character source.
>>   (In terms of OOP, each of these, the parser, the scanner and
>>   the character source might be an individual object.)
>>
>>   It might happen that the parser detects a syntax error.
>>   How can it then report this?
>>
>>   Ok, it might print the token and a diagnostic message.
>>
>>   But the parser does not know the line and the offset in the
>>   line, so it can't print the line number and source context.
>>   This has already been abstracted away by the lower entities
>>   (the scanner and the character source). Usually, the parser
>>   does not need to know these lower-level details.
>>
>>   How does one usually deal with this? (Printing the line number,
>>   the line offset and the region of the source code where the
>>   error was detected when the parser detects an error)
>>
>>   My first idea was to decorate each and every token with
>>   such context information that can be used in the case
>>   of an error, so that the parser then can access it.
>
>This is what I would do.  And I'd be prepared to store quite a lot
>information.  gcc can relate a token back to the macro expansion that
>gave rise it, for example.


I'll second that, and it's what we do.  We keep the starting and
ending position of each token in the preprocessed source, so you can
identify the region containing the error (which might be more than one
token).  We then keep enough context in the preprocessed source to be
able to relate that back to original source position (inclusion
hierarchy, file(s), line(s), position).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web