Olly Betts

xml module doesn't respect field declaration order

It seems not. However, we don't really define what the generated XML looks like - AFAICS we just say: The XML is a dump of SWIG's internal parse tree and as such it is subject to change at any time as and when SWIG's implementation changes. Therefore I'm not sure that the relative order of things in the XML should be expected to reflect declaration order. We're really just dumping SWIG's internal data structure as XML and the data structure in memory isn't ordered in this way. I think consumers probably...

c840bb728a886fd8b9a9f241c2d2b603f0e7a91b changed this code to make type casting threadsafe. It's hard to be sure without having a reproducer, but it looks like the problem may still exist as cast->type is still only updated here if (type == swig_module.type_initial[i]).

We're still generating the same code AFAICS. Retesting though I found it does actually work provided you use consistent naming: $ RUBY=ruby3.2 $ echo '%module OpenBabel' > test.i $ swig -ruby test.i $ g++ -shared -fPIC \ -I"`$RUBY -r rbconfig -e 'puts(RbConfig::CONFIG["rubyhdrdir"] || "")'`" \ -I"`$RUBY -r rbconfig -e 'puts(RbConfig::CONFIG["rubyarchhdrdir"] || "")'`" \ -o OpenBabel.so test_wrap.c $ $RUBY -I. -e 'require "OpenBabel"' $ So if you use %module OpenBabel then you need to name the shared...

I've merged fixes for the remaining cases here - should be released in SWIG 4.4.0.

syntax error when parsing complex default values

Moved to https://github.com/swig/swig/issues/3197 in the live tracker

templates using import fails