[Swig-devel] SWIG preprocessor bug(?): %include nested in %defined macros

[Karl W. <kar...@gm...>]

Hi,

I've come across what seems to me to be a bug in the SWIG
preprocessor: when an %include directive is nested within more than
one macro defined with %define, the included file is parsed by the
preprocessor more than once. For example:

$ cat header.h
#define A 1
#define B 2
#define C 3
$ cat test.i
%module test

%define nested1()
%include <header.h>
%enddef

%define nested2()
nested1();
%enddef

#if defined(NESTED1)
nested1();
#elif defined(NESTED2)
nested2();
#endif
$ swig -E -DNESTED1 test.i | grep . | tail -10
%includefile(maininput="test.i") "test.i" [
%module test
/*@SWIG:test.i,3,nested1@*/
%includefile "header.h" [
%constant A = 1;
%constant B = 2;
%constant C = 3;
]
/*@SWIG@*/;
]
$ swig -E -DNESTED2 test.i | grep . | tail -12
%includefile(maininput="test.i") "test.i" [
%module test
/*@SWIG:test.i,7,nested2@*/
/*@SWIG:test.i,3,nested1@*/
%includefile "header.h" [
%constant 1 = 1;
%constant 2 = 2;
%constant 3 = 3;
]
/*@SWIG@*/;
/*@SWIG@*/;
]

In the second case, when SWIG is run with -DNESTED2, the included file
header.h is parsed by the SWIG preprocessor twice - once when the file
is included when nested1() is expanded, and once when the included
file contents is parsed again when nested2() is expanded. As a result,
the names of the #defined constants A, B, and C are replaced with
their values, which have already been defined as preprocessor symbols,
and invalid code is generated.

This seems like a bug to me, since preprocessing the same code
multiple times is probably going to always lead to invalid code (as in
the example above), and it limits where you can use %include
statements (i.e. not inside macros which may be nested). But perhaps
there are circumstances where this behaviour is needed?? As far as I
can tell none of the SWIG library code relies of this behaviour.

Assuming that this is a bug, I've posted a patch with what I hope is
an acceptable solution here:

https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3468362&group_id=1645

As far as I can tell, this patch doesn't break anything in the test
suite. Of course I'd welcome any suggestions or improvements to the
patch. I hope that there is time to get this issue fixed for version
2.0.5.

Cheers,
Karl