Re: RFC: preprocessor macro support (should actually work now)

[Jim Blandy <jimb at redhat dot com>]

Neil Booth <neil@daikokuya.demon.co.uk> writes:
> I've done a bit more research into examples of when token marking is
> needed when expanding macros.  There are a few in the CPP testsuite;
> here is one (I got this by disabling the feature in CPP and seeing
> what broke):
> 
> #define M(x) 2 + M(x)
> #define N(a) M(a)
> N (N (9))
> 
> The correct expansion is
> 
> 2 + M(2 + M(9))
> 
> I expect your code (though I've not tested it!) will get:
> 
> 2 + M(2 + 2 + M(9))

Yes indeedy:

    (gdb) show macro M
    Defined at /rigel/jimb/gdb/macros/play/macros4.c:4
      included at /rigel/jimb/gdb/macros/play/macros4.c:0
    #define M(x) 2 + M(x)
    (gdb) show macro N
    Defined at /rigel/jimb/gdb/macros/play/macros4.c:5
      included at /rigel/jimb/gdb/macros/play/macros4.c:0
    #define N(a) M(a)
    (gdb) macro expand N (N (9))
    expands to: 2 + M(2 + 2 + M(9))
    (gdb) 

(That `included at macros4.c:0' stuff is a GCC bug I think Daniel B's
working on.)

For spectators: libcpp represents the stream of source code it's
expanding as an array of token structures, not a simple array of
characters.  When it sees some macro named X expand to a sequence that
includes the identifier token X, it sets a flag on that token
indicating that it should never be expanded as a macro invocation.  As
the example shows, this flag may need to remain set long after the
original invocation of the macro named X has been processed.  I don't
see any easy way to get this effect with a string-based expander, like
the one in my patch.

I didn't really understand all the logistics that got brought up
regarding moving libcpp into its own directory in the repository, to
make it easier to share with gdb.  But the sooner that happens, the
sooner we can replace my macro expander with one that works better.