Re: Syntax error messages

[Hans Åberg]

> On 1 Oct 2021, at 23:30, Christian Schoenebeck <schoenebeck@crudebyte.com> 
> wrote:
> 
>> For the purpose of writing out the line in the error messages, this method
>> (using C++) did not work out well, because I have two parsers, one for the
>> language and one for directives, and it turns out to be difficult to pass
>> the location information back to the top parser.
>> 
>> So instead, in addition to the input stream stack, I added two, for the
>> current stream position, and the current stream line position. Because of
>> the lexer buffering, they are computed in the lexer. These are properties
>> attached to the input streams then, not the parser locations.
>> 
>> In the Bison type, I use line number and for columns the number of UTF-8
>> characters. An ASCII caret marking the error is surprisingly accurate even
>> in the presence of non-ASCII characters. But perhaps one should have a
>> method to mark it on the line itself, not underneath.
> 
> Hmm, those two parsers run independently from each other, or do you rather 
> mean you have coupled them in a way that they cross-influence their behaviour 
> *while* they are still running?

Currently the main language parser calls the directive parser so that one can 
set switches for the behavior. The directive parser just reads the current file 
that the language parser provides. But the latter would be desirable say using 
coroutines, because then the directive parser could things that is above the 
main language, such as loading input files (as in the C preprocessor).

> So far I have not encountered any restriction with my location approach. I'm 
> using it for all kinds of things like, of course warnings/errors on the CLI, 
> highlighting of the same in code editors, but also for code refactoring 
> stuff. 
> The latter only works well with a full language aware parser, unlike those 
> typical RegEx hacks.

When calling the directive parser from the language parser, I found it 
difficult to pass the location information back to the language parser, getting 
out of sync, as its current location is an independent copy of the location 
passed to it. Therefore, I switched to using separate stream current and line 
positions, computed in the parsers because of lexer buffering, stacked for 
recursive streams.

One spinoff is that I can have a program startup option --directive="…" which 
calls the directive parser via C++ string stream, saving work for having 
separate options for all that it can do. And error messages work there as well.