On Wed, May 9, 2012 at 11:38 PM, Konrad Eisele <konrad@xxxxxxxxxxx> wrote:
>>> The client can do a custom pass to consume the annotation token. It
>>> should
>>> be able to build the patch tree that lead to the expansion result. The
>>> annotation
>>> token will be consume and removed from the token stream before it get
>>> pass to
>>> the parser.
>
>
> Reading it 2 times and thinking about what kind of thought
> drive you: I can only say this is fucking sick:
> You oppose adding one little TOKEN_M_EMPTY, now you use my idea
> to add 100 new tokens and yeah ... Hello, hello ... How can
> you filter them out : You _cannot_ add a "post" hook. :-) Haha...
I only request some clarification on how you use
the TOKEN_M_EMPTY in the call back. Which you don't care to explain.
It is clear that I consider no call back is better than 2 call back, which
is better than 6 call back. I am not too worry about changing internals
of parse, as long as it is "do the right thing".
Where do you get the idea you can't do custom filtering without
a "post" hook? I already explain to you in previous email
you can call preprocessor and parser step by step yourself.
token = tokenize(filename, fd, NULL, includepath);
token = preprocess(token);
token = my_custom_filter(token);
while (!eof_token(token))
token = external_declaration(token, &translation_unit_used_list);
Do I need to use your post hook? No.
You doesn't want to listen.
I have nothing against you. It is pure technical merit I am evaluating.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
