Simplify implementation for -builtin, which does not need a fallback to
use strcmp as PyType_IsSubtype() 'just works' even when using multiple
modules (I think perhaps because SwigPyObject_stype->clientdata->pytype is
common across modules due to the implementation in SwigPyObject_Type()).
In the non-builtin case SwigPyObject is not a base type and usage is
different and when multiple modules are being used, SwigPyObject_Type()
returns two implementations of SwigPyObject which is solved in a hacky
way by comparing the types as strings when the pointer comparison fails.
Add import_callback test - tests %import and %callback to exercise
all of SwigPyPacked_Check(). Python only - the main callback example is
not widely tested and needs work in most of the other languages.
I tried with -Werror but observed the warning messages disappearing
and tests not failing - probably because the wrapper code is swallowing
warnings and catching the resulting error. Seen in python_overload_simple_cast_runme.py
on Linux (not Windows!). Also when the warning is turned into an error
just a seg fault can occur without the warning message. All round better
to actually see the warning.
A different approach is taken for supporting casting smart pointers up the
inheritance hierarchy. We no longer try to replace the underlying pointer type,
provided in the 'feature:smartptr', with the base class type. Such as morphing
'std::shared_ptr<(Derived)>' into 'std::shared_ptr<(Base)>'. Instead, we simply
use 'feature:smartptr' from the base class. This is more reliable than trying to
pattern match the pointer type in the feature. The base class must of course
also have the 'feature:smartptr' set, and this is still checked for as before.
The feature is now parsed in one place and stored in the parse tree in the
new 'smart' attribute for handling by the target languages.
Fix also improves the handling of the type parsed in 'feature:smartptr' in that
the type is now normalized and resolved in the scope of the class it is attached
to.
Closes#2768
* std_filesystem_python:
Add <type_traits> fragment for traits usage in std::filesystem
Correct const std::filesystem & typemaps
Fix memory leak wrapping const std::filesystem&
std::filesystem pointer handling correction
Python std::filesystem cleanup
Cosmetic whitespace corrections
Try to use wstring/wchar_t on windows
Reformat
Rename the helpers within the fragment to be more uniquely named
Make CI rerun (and output all failed cases for the specialPath)
Address review comments
Need to see which assert is failing on mingw
Verbose assert to try and see the failure on mingw
path::string() returns a copy not a const ref.
Remove cpp17_std_filesystem from common.mk, only defined for Python for now
Extend roundtrip test
Address review comment by @degasus on #1999 originally
Had trouble getting the test to be properly ignored. If I wrap the inline line 35 in #if __cplusplus the wrapper code isn't generated
Tweak tests setup
Cherry pick from yasamoka/master
Conflicts:
CHANGES.current
Fix when variable override contains a pointer dereference ->.
This enables use of $1.x as a variable override value as SWIG
replaces $1.x with a pointer dereference expression, such as
(&arg1)->x.
Added a testcase showing how Python typemaps could alternatively
be written using $typemap() instead of using C++ templates as used in
the UTL. I'm not convinced this is fully reliable or even a good idea,
so the variable replacements in $typemap() remain undocumented.
Support running testcases conditional on the compiler supporting
a each language version, like we already handle C++11.
Currently no testcases are actually run in this way for these
newer language versions.
Move HAVE_CXX11 into makefiles so that running test-suite
from top level directory or in the language's test-suite directory
is consistent. For example, running 'make check-java-test-suite'
behaves the same as 'cd Examples/test-suite/java && make check'.
* feature/python-builtin-separate-runtime-data:
Rework swig_and_compile_multi_cpp makefile helper
Different capsule names for builtin changes entry
Use different capsule names with and without -builtin
Conflicts:
CHANGES.current
Types generated with and without -builtin are not compatible. Mixing
them in a common type list leads to crashes. Avoid this by using
different capsule names: "type_pointer_capsule" without -builtin and
"type_pointer_capsule_builtin" with.
See #1684
Both function annotations and variable annotations are turned on using the
"python:annotations" feature. Example:
%feature("python:annotations", "c");
struct V {
float val;
};
The generated code contains a variable annotation containing the C float type:
class V(object):
val: "float" = property(_example.V_val_get, _example.V_val_set)
...
Python 3.5 and earlier do not support variable annotations, so variable
annotations can be turned off with a "python:annotations:novar" feature flag.
Example turning on function annotations but not variable annotations globally:
%feature("python:annotations", "c");
%feature("python:annotations:novar");
or via the command line:
-features python:annotations=c,python:annotations:novar
Closes#1951
Python function annotations containing C/C++ types are no longer
generated when using the -py3 option. Function annotations support
has been moved to a feature to provide finer grained control.
It can be turned on globally by adding:
%feature("python:annotations", "c");
or by using the command line argument:
-features python:annotations=c
The implementation is designed to be expandable to support different
annotations implementations. Future implementations could implement
something like the following for generating pure Python types:
%feature("python:annotations", "python");
or typing module types to conform to PEP-484:
%feature("python:annotations", "typing");
Closes#1561
Issue #735
template_typedef_cplx2 files are generated by the template_typedef_import.multicpptest
but can also be cleaned by the template_typedef_cplx2.cpptest target.
* commit '8245277ad3acd9308ce28c40508b999e9496b27e':
Remove test for unsupported complex or _Complex by itself
More C99 complex fixes, plus Python tests
Restore _Complex as standalone type
Small corrections for handling C99 _Complex
Properly handle C99 complex types even in C++ mode
Conflicts:
Examples/test-suite/python/complextest_runme.py
* remove-dependency-on-2to3:
Remove need for Python 2to3
Modify examples to be both Python 2 and 3 compatible
Remove python3 specific runme3.py test files
Convert python tests using 2to3
Convert python test scripts to be Python 2 and 3 compatible
Convert swigobject python test to be python 2 and 3 compatible
Convert two tests to work with both Python 2 and 3
Improve director_exception Python test
Remove further print statements from Python tests
Improve Python testing catching exceptions
Improve contract Python testcase testing
Remove print statements from Python tests
All Python examples and tests have been written to be both Python 2 and Python 3
compatible, removing the need for 2to3 to run the examples or test-suite.
The 2to3 executable is not always available and even when available does not
always work, e.g. with pyenv. An alternative would be to use the lib2to3 Python
module instead, but this isn't available in some older versions of Python 3.
I had this problem on Ubuntu Bionic on Travis:
checking Examples/python/callback
pyenv: 2to3-3.8: command not found
The `2to3-3.8' command exists in these Python versions:
3.8
3.8.1
Reference issues:
https://github.com/pypa/virtualenv/issues/1399https://travis-ci.community/t/2to3-command-not-found-in-venv-in-bionic/4495
This error is given for any use of variable called "l" (and also "I" and
"O", but we don't seem to have any of those) and it doesn't seem to be
worth changing this variable name in the tests code, as it's really not
that meaningful there anyhow, so just disable the warning to let the CI
builds, which now use pycodestyle 2.6, instead of 2.5 which didn't have
this error and which is still the latest available in Debian Sid, pass.
This testcase was only run in Ruby and Python and implements an
obscure feature where a C++ class inherits from a std::wstring.
The li_std_wstring test is left in place to be modified in next commit
for more regular wstring testing across all languages.
- 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.
William S Fulton