The existing code didn't work correctly for strings longer than 2GB.
This does require using at least Go 1.20, but that should be OK as
the last currently supported version of Go is 1.22.
This restores commit ff5c118aaa which
was rolled back by commit fe3a7af855
because Go was generating C code that uses declarations after
statements. The original commit now works because 1) commit
e0ecea47b1 sets the C standard to use,
and 2) the current minor versions of the relevant Go releases were
fixed to put the declarations first.
Fixes#3125
Implements https://peps.python.org/pep-0489/
Bumps minimal python3 version from 3.4 to 3.5.
The idea is to move the initialization of the module into a new SWIG_mod_exec function.
Closes#3168
for default case (they have just been added for -builtin and
SWIG_HEAPTYPES in previous couple of commits).
These are only used by -builtin and were missed when when moving
SwigPyObject, SwigPyPacked and SwigVarLink were added to the swig
runtime module. Should fix potential warnings for these two types:
DeprecationWarning: builtin type has no __module__ attribute
although this has not been seen in the test-suite.
GHA - python-3.14 testing changed to "can fail" as 3.14 is still in alpha status.
Restore __package__ fallback check as it was.
Correct docs given the import changes.
Issue #3159
Issue #2967
more
For example:
%typemap(in) int MYINT (int $1_temp) { ... }
$1_temp is typically expanded to arg1_temp, arg2_temp etc depending on
which argument the typemap is applied to.
Perform repeated typedef lookups instead of a single typedef
lookup on the type being applied in %apply when looking for a family
of typemaps to apply.
Closes#3064
This is described in CHANGES as a "Secret developer feature" and
a "SICK HACK". It was only documented in developer documentation, and
had no test coverage.
It allowed specifying an SWIG internal syntax type string, e.g.
`p.a(10).p.f(int, p.f(int).int)` foo(int, int (*x)(int));
However there seems to be no good reason to support this - it's
better to use the C/C++ syntax:
(*(*foo(int, int (*)(int)))[10])(int, int (*)(int));
Fixes#2998Closes#3034
Latest Visual Studio 2022 is unable to update/convert these project files.
It appears that Perl, R, Ruby use gcc mingw on Windows nowadays to compile
extensions, so Visual C++ is no longer supported (maybe incorrect, but it
is not clear to me how to compile C/C++ extensions for these languages
with Visual C++ nowadays).
Complete the removal of Ruby's output_helper macro and replacement
with SWIG_AppendOutput for director typemaps.
Requires $isvoid special variable support in director code.