closes#1374
* enhance testing around multiple return values
Examples/test-suite/perl5/scilab_multivalue_runme.pl fails in
perl-5.28.1 compiled with -DDEBUGING without the typemap updates
* repair EXTEND() handling in typemaps
* Use PL_sv_undef for VOID_Object
This examples tests the SWIG generated module being placed into a directory and
then renamed __init__.py to convert the module into a package. This ability
stopped working in swig-3.0.9. However, only Python 2.7 or 3.3 and later work. If
Python 3.2 support is needed, use moduleimport in %module to customise the import
code.
Issue #1282
* vadz-add-nested-in-template-test:
Avoid comparing doubles in nested_in_template.i unit test
Add recently added nested_in_template to the list of test cases
Getting these kind of errors on Appveyor which uses mingw/cygwin to run
a Python interpreter:
Native windows Python 3.6 running under cygwin and mingw Python 3.7 running under mingw:
Fatal Python error: _Py_HashRandomization_Init: failed to get random
numbers to initialize Python
Cygwin Python 2.7 running under cygwin:
0 [main] python2.7 496 child_info_fork::abort: address space needed by '_foo.dll' (0x6D0000)
is already occupied
* adr26-master:
Cleanup accessing/decref of globals, to avoid code bloat in init function.
Fix ISOC build errors.
Fix unused variable warning.
#1360: Leak of SWIG var link object
Conflicts:
CHANGES.current
When using -builtin, the two step C-extension module import is now
one step and the wrapped API is only available once and not in an underlying
module attribute like it is without -builtin. To understand this, consider a
module named 'example' (using: %module example). The C-extension is compiled into
a Python module called '_example' and a pure Python module provides the actual
API from the module called 'example'. It was previously possible to additionally
access the API from the module attribute 'example._example'. The latter was an
implementation detail and is no longer available. It shouldn't have been used, but
if necessary it can be resurrected using the moduleimport attribute described in the
Python chapter of the documentation. If both modules are provided in a Python
package, try:
%module(moduleimport="from . import _example\nfrom ._example import *") example
or more generically:
%module(moduleimport="from . import $module\nfrom .$module import *") example
and if both are provided as global modules, try:
%module(moduleimport="import _example\nfrom _example import *") example
or more generically:
%module(moduleimport="import $module\nfrom $module import *") example
The module import code shown will appear in the example.py file.
The implementation for a renamed constructor for -builtin no longer
uses the same implementation for non-builtin mode which makes a call
into the compiled C module, eg _constructor_rename for a module called
constructor_rename. The output in the constructor_rename.py file is now:
RenamedConstructor = new_RenamedConstructor
instead of
def RenamedConstructor():
val = _constructor_rename.new_RenamedConstructor()
return val
when wrapping:
struct Foo {
%rename(RenamedConstructor) Foo();
Foo() {}
};
See the constructor_rename.i testcase.
This change has been made to make the wrapper more efficient and is a
step towards the next commit which will remove duplicating the symbols
in both the pure Python module and implementation C module
(constructor_rename and _constructor_rename respectively in this case).
Code handling %template in the parser created a totally new top-level
module child of namespace type when handling templates inside a
namespace and copied the nodes from the previously parsed C++ template
declaration to it. However copies of this node kept their original
values of "abstracts" attribute, which contained pointers to the classes
in the original template declaration, i.e. outside of the subtree
created for the instantiated template. This, in turn, meant that during
the types resolution pass, the code in TypePass did not update the types
used in the methods of the classes appearing in the "abstracts" List,
even though it did update the types for the children of the instantiated
template subtree.
And this finally resulted in wrongly detecting overridden virtual
methods as abstract in Allocate::is_abstract_inherit() during the next
pass, as the signatures of the overridden method -- using resolved types
-- and of the method from the class pointed to by "abstract" -- using
the original types from C++ code -- didn't match.
Resolve this simply by not copying "abstracts" attributes when creating
the template subtree and doing another pass over this tree to recreate
them using the new nodes, just as it's already done for "defaultargs"
attribute, presumably for similar reasons. Note that doing another pass
over the tree is not as efficient as doing everything in a single pass,
but merging the new update_abstracts() with update_defaultargs() is not
completely obvious, so for now keep it simple and optimize it later if
necessary.
Also, add a test checking for the situation described above.
Closes#1353.
When using the moduleimport option, such as:
%module(moduleimport="import $module") example
the minimum Python version check disappeared from the generated Python
file. The code has been refactored and _swig_python_version_info is
no longer deleted after initial use as it can be used in a few places,
in particular, when -builtin is used.
cparse_template_expand() incorrectly appended template parameters to all
destructor nodes it encountered during the tree traversal, including the
dtors of any nested classes.
This resulted in WARN_LANG_ILLEGAL_DESTRUCTOR warnings from
Language::destructorDeclaration() later and possibly other problems due
to not actually wrapping these dtors.
Fix this by explicitly checking if the dtor is a child or, to account
for %extend, a grandchild of the template node itself before appending
template parameters to it.
This commit is best viewed with "-w" (ignore whitespace changes) option
as it indents, without changing, a block of code.
Set paths correctly for msys2 + mingw. With this correction, there is no
need to override the default gcc.
Provide a way to specify the name of the python interpreter using
a WITHLANG env variable. Needed where the native python3 executable is
called python.exe which is needed and not MinGW's pre-installed python3.exe.
