Re: Fwd: dependency tee from c parser entities downto token

[Konrad Eisele <eiselekd@gmail.com>]

On 05/11/2012 09:40 PM, Christopher Li wrote:
> On Thu, May 10, 2012 at 5:28 AM, Konrad Eisele<eiselekd@gmail.com>  wrote:
>>
>>>> A change like this is bound to need some careful discussion and
>>>> planing. Yes, I am guilt of only accepting patches meet some subjective
>>>> stander of mine. But so is to any self respect project maintainers.
>>>> I would rather spend some time to do it right than commit some thing
>>>> I would regret later on.
>>>
>>>
>>> Do a B(B(x)) and your sym->parent linked-list will fail.
>
> You have a valid point that B(B(x)) will break the sym->parent list.
> I remove the sym->parent and just use a token_list to maintain the
> expanding macro. The macro is append to the list when enter and remove
> from the list when untaint token is reached. The change is in the
> same review branch.
>
> That should solve this problem?

This seems ok. expanding_macro has to be global not static to be
used... (?)

>
>> I have to revise my previous assumption though:
>>
>> #define B(y) A(x)
>> B(1)
>>
>> i thought that in the body expansion of B recursion is involved,
>> so that it would yield:
>>
>>   expand_macro(A);
>> expand_macro(B);
>>
>> but that was wrong, so its
>>
>> expand_macro(B);
>> expand_macro(A);
>
> That is right. The macro expansion has 3 stages. The first stage is
> expand the arguments list while the caller macro does not consider
> "tainted" during the argument expansion. The macro can recursively
> appear in the argument list. That is some thing I haven't consider
> previously.

I think the fact that argument expansion is recursive and
body expansion is non-recursive is one of the things that
make the preprocessor kindof hard to grasp.

>
> The second stage is just replace the expanded arguments into body.
>
> The third stage is rescan the replacement string for macro expand.
> In this third stage, the macro itself is consider tainted and can't be
> expand again during the rescan.
>
> Can you take a look at this modify version will fit your need or not?
> I am curious the part weather that will remove the need to add
> empty token to the list for expansion.

I cannot say this before I've tried it.

I'd like to straighten things out a bit: My last emails
where a bit too harsh and I'd like to apologize. Sorry
for that.

The next step then is: I'll write a patch to add a
test-prog that uses this api to trace the token generation
and generate a tree for it.
For a start I'll printout for all tokens of a preprocessor
run all macros-expansions that generated them.

Now, I've learned not to run too fast towards the
goal, (which is still "dependency tee from c parser entities downto
token"), maybe you can think about how to achieve the next steps
in an API :
- An #include #ifdef #else #endif pushdown-stack
   to record the nestings for each token
- How to connect all this to the AST.

-- Konrad

>
> In order words, can we design the API clever enough that you
> don't need to jump through hoops to handle the empty expansion
> token.
>
> Thanks
>
> Chris
>