Re: nyacc 0.73.0 released

[Jan Nieuwenhuizen <janneke@gnu.org>]

Matt Wette writes:

Hi Matt!

>> Also, it seems like it doesn't like it if an #includ'ed file is meant to
>> go inside a function, like (simplified example)

> So this is a bug.  And I am not sure how to proceed yet.  The parser
> was designed to return a AST with code from includes under a subtree.
> This allows a file to be processed with respect to code only in that
> file.  The way it works is to parse the included file as a new parse.
> That only works at the top level.  This breaks for files included
> inside functions etc.

That makes sense.

> How are you processing the file?  Do you want to be able to
> discriminate between a file and the included files, and only if
> included files are at the decl level (e.g., #include <stdio.h>) but
> code inside functions gets included as is (i.e., the AST looks as if
> the code was in the parent file)?

For a user, best is to have error messages that point to the file+line
where the actual code is; so in each case the included file.  Gcc's cpp
always adds # <line> "<file>" markers; it makes no difference where the
file is included.

What I am currently doing, is generate lists of symbol declarations and
definitions by snarfing the original mes.c file.  The declarations are
included at toplevel, which is fine.  The definitions go inside
functions.

So for my specific use case it does not really much either way, although
having correct file:line:message error messages is nice. ;-)

> This will take some sort of parser-lexer hook I think.  I want to
> think about a clean architecture for all the use cases.

Sure.

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl