> On Dec 31, 2016, at 6:15 AM, Jan Nieuwenhuizen <jann...@gnu.org> wrote:
>
> Matt Wette writes:
>
>> I believe C99 parser is complete. There may be errors, but I think
>> all the elements are there.
> Also, it seems like it doesn't like it if an #includ'ed file is meant to
> go inside a function, like (simplified example)
>
> --8<---------------cut here---------------start------------->8---
> // main.i
> r = 3;
> --8<---------------cut here---------------end--------------->8---
>
> --8<---------------cut here---------------start------------->8---
> // main.c
> int
> main ()
> {
> int r;
> #include "main.i"
> return r;
> }
> --8<---------------cut here---------------end--------------->8---
>
>
> ==> ./main.i:2: parse failed at state 43, on input "r"
Jan,
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.
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)?
This will take some sort of parser-lexer hook I think. I want to think about a
clean architecture for all the use cases.
Matt
