Making this a command line option seems unhelpful - it's something the user is likely to need to specify for a particular interface file (because it's something that is likely to be needed based on particular uses of attributes in third party headers they're trying to wrap), so it would be better to be able to specify it in the interface file (if it's a global setting, perhaps as a parameter on %module; if it's something that's useful to control in a more fine-grained way, perhaps as a %feature. I can see one might theoretically want it on for one wrapped header but not another, but that may be a bit of a contrived example).

I did mostly because the specifications for [[attribute]] are very vague and I am afraid that now that parsing is implemented and mandatory, there might be cases where the parser wouldn't expect an [[attribute]] and this header won't pass at all in SWIG.

It seems reasonable to have a way to switch attribute handling back to the current "just ignore them in the lexer", I'm just saying making it a command line option seems the wrong approach for how to specify this.

This is a parser option, it does not belong in the parsed text. Since an attribute cannot contain a %feature it can be made to work, but still, I don't think it belongs there.

Defining a macro with a reserved name makes the program ill-formed so it'd be better to use e.g. BIGGEST_ALIGNMENT. If it actually matters to use __BIGGEST_ALIGNMENT__ when it is defined by the compiler we could define it using

#ifdef __BIGGEST_ALIGNMENT__
#define BIGGEST_ALIGNMENT __BIGGEST_ALIGNMENT__
#else
#define BIGGEST_ALIGNMENT 16
#endif

and then use BIGGEST_ALIGNMENT below.

I don't think this is the only anti-pattern in the unit tests, this will only add additional clutter.

Please change this.

The point here is to ensure that SWIG can parse int b = a[a[0]]; (in particular that the ]] is broken apart properly. SWIG doesn't parse function bodies, so moving this code into a function body doesn't actually test what was intended here.

(The reason this part is currently deactivated is just that the parser doesn't currently actually handle a double array dereference in an expression, but once that is fixed we want to be testing this properly.)

It will still have to be tokenized if attributes parsing is disabled - this is the only case when this could not work.

The parser just skips tokens between the { at the start of a function body and its matching closing }, so putting it in a function body will parse OK even if the ]] is scanned as a single token.

The next time you permit yourself to make a comment in order to pass a criminal message, I will seriously reconsider my decision from last year to skip sending an email to the legal department of every institution mentioned in the SWIG license files to inform them of a copyright problem involving plagiarism for a criminal extortion related to a series of falsified legal procedures in the EU. I will be completely honest and I will attest that you most probably do not have anything to do with the organized judicial and police corruption, the sexual elements, the international prostitution ring or the drug trade taking part in this affair. My patience has limits.

@mmomtchev, this last comment appears threatening, is not constructive and is not welcome in the collaborative SWIG development community that we strive for. @ojwb is merely trying to help review and improve your (very welcome) contribution. I don't understand the comment as it appears out of context and I hope it has been posted on the wrong issue, in which case, please withdraw it. If not and if you have some non-technical issue about SWIG that you would like to discuss, please raise a separate discussion thread. Otherwise, I ask you to kindly keep discussions on topic to C++11 attributes. Thank-you for you understanding.