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
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.
What SWIG calls "modern" classes are supported by Python 2.3 and up
which means they're supported by all the Python versions we aim to
support in 4.0.0.
Conflicts:
Source/Modules/python.cxx
This is a cherry-pick and merge from the patch in #1261
There were only needed to support Python < 2.2, and we now require at
least Python 2.6.
Conflicts:
.travis.yml
Examples/test-suite/python/autodoc_runme.py
Source/Modules/python.cxx
This is a cherry-pick and merge from patch in #1261
Add runtime test for scenario described in #1323.
Expand testing to cover a mix of override/virtual method overloading.
Remove testSwigDerivedClassHasMethod() test - not fixed yet.
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.
Found via `codespell -q 3 -L "uint,bae,objext,cmo,goin,struc,ois,upto"`
whitespaces were unintentionally fixed due to my editors settings.
Rebased patch #1327
- 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
When there is just a _runme3.py file and no _runme.py file, out of
source builds were not running the script.
Currently only applies to python_abstractbase_runme3.py.
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.
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
