[PATCH 1/2] gcc symbol database

[Dodji Seketeli]

Yunfeng ZHANG <zyf.zeroos@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