Yunfeng ZHANG <zyf.zer...@gmail.com> writes:
> Please allow me to resend former sample:
> #define Z(a) a
> #define Y Z
> #define X(p) p + Y
> X(1)(2);
> The flow is:
> 1) `X' -- leader macro token by macro_start_expand.
> 2) `(', `1', `)' -- macro tokens, by cb_lex_token.
> 3) macro_end_arg.
> 4) `1', `+' -- macro replacement tokens, by symdb_cpp_token.
> 5) `(', `2', `)' -- macro tokens, by cb_lex_token.
> 6) macro_end_arg.
> 7) `2' -- macro replacement tokens, by symdb_cpp_token.
> 8) macro_end_expand.
>
> The thing I emphasized here is cb_lex_token is set by macro_start_expand
> intern -- it isn't valid anytime.
It took me a couple of minutes to understand what you meant here, so
please let me re-phrase to make sure I got it.
You are saying that the callback function of the cb_lex_token event is
set by the callback function of the macro_start_expand event.
Is that correct?
> So
> buff = funlike_invocation_p (pfile, node, &pragma_buff,
> ...
> if (buff == NULL)
> {
> ...
> }
> if macro_start_expand is moved to the clause block `buff != NULL', it's too
> later to set cb_lex_token because funlike_invocation_p has read some macro
> tokens.
Then for function-like macros, you can move the call to
macro_start_expand into funlike_invocation_p, right before it calls
collect_args (collect_args is the function that reads the macro
arguments).
And this makes me wonder why you'd need the second parameter of
macro_start_expand (the token). I believe you should have all the
information you need with the first, second, and last parameter. As I
said in my previous email, you can get the file offset of the token in
your client code by doing 'file_offset = line + column'. So that token
should not be needed. Thus, calling macro_start_expand from inside
funlike_invocation_p once you are sure the expansion of the macro is
going to take place, is possible.
For non-function-like macros, you can call macro_start_expand after the block
if (macro->fun_like)
{
inside enter_macro_context.
> Of course I can remove macro_end_arg totally, because from the sample, it's
> the
> fact that macro tokens aren't always before any macro replacement tokens. But
> macro_end_expand must be prepared to deal with cancel case.
I still think that with the plan above, you don't need any cancel case
because macro_start_expand is going to be called only when we know the
macro is going to be expanded.
--
Dodji
