#333 [PATCH] Parse defines inside enums

[Younes Manton]

This allows the main libbfd header to be parsed. Patch is against 2.0.9.

[Olly Betts]

Do you have an isolated test case for the problem this is trying to solve?

We really want to have test coverage for something like this to make sure we don't break it with changes in the future.

(I've checked the current testsuite with the patch and it doesn't seem to break anything).

[Younes Manton]

Here's a minimal example that shows the problem:

test.h

enum foo
{
alpha=0,
#define bar -1
beta=1
};

test.i

%module test
%{
#include "test.h"
%}

%include "test.h"

Without patch:

$ swig -python test.i
test.h:4: Error: Syntax error in input(1).

With patch:

$ swig -python test.i

[Olly Betts]

Oh, this rings a bell now - it was reported here:

https://sourceforge.net/p/swig/bugs/428/

The testcase there was pretty similar:

typedef enum {
eZero = 0

define ONE 1

} EFoo;

Thanks very much for your testcase. I'll slot it into the testsuite and commit this soon.

[William Fulton]

The patch was unsuitable as it started skipping some enums values and didn't allow macros to be defined everywhere in the enum list. I've fixed this up though and committed for swig-2.0.10. Thanks for the start though.

BTW, why are macros defined in enums like this? I can't see the point.

[Younes Manton]

Locality of reference I suppose. I didn't write the header I needed parsed but for some enums it had related macros defined right below.

Thanks for fixing it.

[Thomas Brain]

This is still broken when two #defines are declared back-to-back in the header. i.e.

enum FooEnum {
  ENUM1 = 0,
  ENUM2 = 1,

#define MACRO_DEF1 "Hello"
#define MACRO_DEF2 "World!"

  ENUM3 = 2,
  ENUM4 = 3,
};

The second #define fails

[Olly Betts]

The two #define case was fixed in SWIG 4.0.0 (thanks to your report).