[cfe-dev] Returning original parsing state after parsing arbitrary tokens

[Eli Friedman]

On Wed, Oct 24, 2012 at 2:39 AM, ja_comp <ja_comp at yahoo.com> wrote:
> Eli Friedman wrote
>> On Tue, Oct 23, 2012 at 3:02 AM, Eli Friedman <
>
>> eli.friedman@
>
>> > wrote:
>
>>> It's impossible to completely save/restore the state of semantic
>>> analysis short of using fork() or equivalent.
>
>> This is a slight exaggeration; that said, parsing a statement in
>> thegeneral case can change essentially arbitrary pieces of the AST andthe
>> lookup data-structures in Sema, particularly in C++ when
>> templateinstantiation is involved.  Even in C there are bits stored in the
>> ASTlike whether a declaration is used which can't be easilysaved/restored.
>
> The sub-goal is to parse the parameters of function-like macros to produce
> StmtResults without altering the normal parsing. While all macro parameters
> may not be well formed, most will likely produce valid results after calling
> ParseStatement.
> The goal is to facilitate source-to-source translation by walking the AST.
> Maintaining the original parameters for function-like macros is desirable in
> this task.
> (I realize that having a valid StmtResult is only half of the equation to
> determining if the parameter makes sense to be parsed in isolation. The next
> task is to expand the macro to a canonical form using the obtained
> StmtResult, and compare against a canonical form of the "normally parsed"
> already expanded macro)
> My code to parse macro parameters works on simple cases, but not when
> including certain headers because of parsing state changes.
> Would you recommend I resort to fork() and messaging, or is there a more
> elegant solution to keep the parsing state pristine?

Hmm... the problem is, semantic analysis is really not designed to
deal with something like this.  Even if you ignore template
instantiation, an arbitrary declaration still inserts things into the
AST which can't be easily removed.  If you can reject input code which
contains any  declarations before it hits semantic analysis, and don't
need to deal with input code that uses templates, that should suppress
most of the ripple effects I can think of, though.

-Eli