Christopher Li wrote:
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.
You didnt get it. The "_cannot_" was ironic. There is always
a way you can fit things. The point is you want to implement it
yourself, exaclty the way you think it should be done, then do it.
I've nothing to contribute.
I've also nothing against you personally, only against this
ping pong emailing. It takes too much time.
-- By Konrad
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
