Test added to check fixes for:
- Issue #948 and issue #1019 and issue #1273 - raw string delimiters
not being stripped off
- Issue #538 - Ruby support for "docstring" feature
The docstring was not encapsulated within /* */ comments.
The implementation had code for autodoc strings being either single or
multi-line and then adding extra newlines. However, in practice only multi-line
autodoc string are ever generated, so this bit of code handling was removed.
The docstring feature does not attempt to add newlines depending on the
existence of newlines in the docstring.
Closes#538
Global functions previously generated two definitions, eg:
def foo():
return _example.foo()
foo = _example.foo
The first definition is replaced by the second definition and so the second definition
is the one used when the method is actually called. Now just the first definition is
generated by default and if the -fastproxy command line option is used, just the second
definition is generated. The second definition is faster as it avoids the proxy Python
method as it calls the low-level C wrapper directly. Using both -fastproxy and -olddefs
command line options will restore the previously generated code as it will generate both
method definitions.
With this change, the wrappers for global C/C++ functions and C++ class methods now work
in the same way wrt to generating just a proxy method by default and control via
-fastproxy/-olddefs options.
Closes#639.
* java-director-thread-name:
Add changes entry for setting Java thread name
Increased Java thread name size.
Java directors - more generic thread name setting
Use prctl method to get thread names, which is available on all NDK versions
Actually, pthread_getname_np is only available in recent versions of Android (API level >= 26).
Set thread name when attaching to Android JVM in SWIG Java director
* python-obfuscated-import-errors:
More Python module loading simplification
Simpler Python module loading
The Python module import logic has changed to stop obfuscating real ImportError problems.
Only one import of the low-level C/C++ module from the pure Python module is
attempted now. Previously a second import of the low-level C/C++ module was attempted
after an ImportError occurred and was done to support 'split modules'. A 'split module' is
a configuration where the pure Python module is a module within a Python package and the
low-level C/C++ module is a global Python module. Now a 'split module' configuration is
no longer supported by default. This configuration can be supported with a simple
customization, such as:
%module(package="mypackage", moduleimport="import $module") foo
or if using -builtin:
%module(package="mypackage", moduleimport="from $module import *") foo
instead of
%module(package="mypackage") foo
See the updated Python chapter titled "Location of modules" in the documentation.
Closes#848#1343
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
* 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.
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.
Fix when using -builtin and wrapping std::map, std::set, std::unordered_map or
std::unordered_set to ensure __contains__ is called. This is a wrapper for the STL
container's find method. Without it, Python will do its own slower sequence search.
- std::unordered_map compilation fix when just using std_unordered_map.i standalone
- std::unordered_multimap compilation fix when just using std_unordered_multimap.i standalone
- Add in the standalone unordered STL test cases
Closes#1319
The previous implementation failed with Python 3 and abstract base clases.
The new implementation replaces the Python 2 implementation using new.instancemethod with C API PyMethod_New to match the equivalent Python 3 implementation which uses PyInstanceMethod_New.
Closes#1310
Further crash fixes when using OUTPUT and INOUT typemaps in typemaps.i and
passing NULL pointers in C++ to director method overloaded and implemented
in Java.
Don't create the one element array in these directorin typemaps if the
input is a NULL pointer, that is, translate a NULL C++ pointer into a
null Java object.
Also add some missing JNI error checks in these typemaps.
* python-type-error:
Python fastdispatch error message improvements
Correct PyErr_Fetch/PyErr_Restore variable names
Overloaded C++ function Python wrappers now raise a TypeError instead of NotImplementedError
When overloaded C++ methods are called, the fastdispatch mode sometimes
optimises out the generation of the typecheck typemap code, resulting in
the 'Possible C/C++ prototypes' information not being in the error message.
Now when a TypeError is thrown, the exception message is modified to contain the
'Possible C/C++ prototypes'.
See issue #1293
Occurs when the types passed are incorrect. This change means
there is now consistency with non-overloaded function wrappers which have always
raised TypeError when the incorrect types are passed.
See issue #1293
