[cfe-dev] Rewriter in a macro

[Ronan Keryell]

>>>>> On Fri, 25 Jan 2013 11:23:38 -0800 (PST), JohnH <jan.hoogerbrugge at gmail.com> said:

    JohnH> Hi, It seems that when I rewrite source code with the
    JohnH> Rewriter class where the source code comes from an expanded
    JohnH> macro that the rewrite does not take place. If I would make a
    JohnH> source-to-source transformation that rewrites while-loops to
    JohnH> for-loops then the following code:

    JohnH> #define WHILE(x) while(x)

    JohnH>   WHILE(cond) ;

    JohnH>   while(cond) ;

    JohnH> would become:

    JohnH> #define WHILE(x) while(x)

    JohnH>   WHILE(cond) ;

    JohnH>   for(;cond;) ;

    JohnH> Is this a known limitation of the Rewriter class?

I do not know but this is an inherently intractable issue with
source-to-source transformation in presence of a macro processor or
template system because there is no semantics associated to what macro
or template represent really.

For example, imagine you have
#define W w
#define HILE(x) hile(x)

        W##HILE(x)

Do you plan to have your program rewritten as
#define W f
#define HILE(x) or(x)

        W##HILE(x)

?

And what if W and HILE are also used in another context with different
semantics and you do not want it to be changed there, such as:
#define W w
#define HILE(x) hile(x)

puts("This is a complex " ##W "orld");
        W##HILE(x)

which displays "This is a complex world"

Is it to be changed to:
#define W f
#define HILE(x) or(x)

puts("This is a nice" ##W "orld");
        W##HILE(x)

which displays "This is a complex forld"
?

I've not tested these contrived examples, so there have certainly some
errors and they may need another level of macro expansion to have
the ## working, but you get the idea :-)

I work also on some source-to-source translator projects and it is
something difficult to do in the real life. The heuristic we use right
now is to do the transformations on the expanded source and try to
recover the #include afterwards.

This is a simplistic approach which is wrong in the general case but
this does not give that bad results in real life.

Anyway, I'm interested by hearing more about any solutions about your
issue and others in this area. :-)
-- 
  Ronan KERYELL                            |\/  Phone:  +1 650 386 6482
  SILKAN Wild Systems                      |/)
  4962 El Camino Real #201                 K    Ronan.Keryell at silkan.com
  Los Altos, CA 94022                      |\   skype:keryell
  USA                                      | \  http://silkan.com