Go, Guile, Racket, Scilab: Add throws typemaps for std::string so that
thrown string exception messages can be seen.
Test all language for std::string throws typemaps
For implementing full move semantics when passing parameters by value.
Based on SWIGTYPE && and std::unique_ptr typemaps which implement move
semantics.
Added for all languages, but untested for: Go, Ocaml, R, Scilab (and
unlikely to be fully functional for same reasons as for std::unique_ptr
support).
Issue #999
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.
Most of these test D_d twice when they really should be testing
D_d once and D_i once (the variable name is `di` and the values
assigned are integers).
This was wrong in the initial version for Python in
708021a809 and it looks like subsequent
additions for other languages have just copied that mistake.
The C++ wrappers create a temporary variable for a parameter to be passed to a
function. This is initially default constructed and then copy assigned from the
instance being passed in from the target language. This is unchanged, however,
when the temporary variable is passed to wrapped function, it is now done using
std::move. If the type is move constructible, the move constructor will be used
instead of the copy constructor.
Note that the implementation calls std::move for all user-defined types
(non-primitive types passed by value), this excludes anything passed by pointer,
reference and arrays. It does also include any type that has not been
defined/parsed by SWIG, that is, unknown types. std::move is called via the
SWIG_STD_MOVE macro which only calls std::move for C++11 and later code.
This is the current state of play where the copy constructor and copy
assignment operators are called, even for movable types passed as
function parameters.
The directorin typemaps in the director methods now use std::move on the
input parameter when copying the object from the stack to the heap prior
to the callback into the target language, thereby taking advantage of
move semantics if available.
Enhance SWIGTYPE "out" typemaps to use std::move when copying
objects, thereby making use of move semantics when wrapping a function returning
by value if the returned type supports move semantics.
Wrapping functions that return move only types 'by value' now work out the box
without having to provide custom typemaps.
The implementation removed all casts in the "out" typemaps to allow the compiler to
appropriately choose calling a move constructor, where possible, otherwise a copy
constructor. The implementation alsoand required modifying SwigValueWrapper to
change a cast operator from:
SwigValueWrapper::operator T&() const;
to
#if __cplusplus >=201103L
SwigValueWrapper::operator T&&() const;
#else
SwigValueWrapper::operator T&() const;
#endif
This is not backwards compatible for C++11 and later when using the valuewrapper feature
if a cast is explicitly being made in user supplied "out" typemaps. Suggested change
in custom "out" typemaps for C++11 and later code:
1. Try remove the cast altogether to let the compiler use an appropriate implicit cast.
2. Change the cast, for example, from static_cast<X &> to static_cast<X &&>, using the
__cplusplus macro if all versions of C++ need to be supported.
Issue #999Closes#1044
More about the commit:
Added some missing "varout" typemaps for Ocaml which was falling back to
use "out" typemaps as they were missing.
Ruby std::set fix for SwigValueWrapper C++11 changes.
If a "docstring" feature is present it will still override a Doxygen comment.
If the "autodoc" feature is also present, the combined "autodoc" and "docstring"
will override the Doxygen comment. If no "docstring" is present then the
"autodoc" feature will not be generated when there is a Doxygen comment.
This way the "autodoc" feature can be specified and used to provide documentation
for 'missing' Doxygen comments.
Closes#1635
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
pyabc.i for abstract base classes now supports versions of Python
prior to 3.3 by using the collection module for these older versions.
Python-3.3 and later continue to use the collections.abc module.
The -py3 option no longer has any effect on the %pythonabc feature.
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
Testing is skipped where there is no support for it, that is,
using -builtin or -fastproxy. How to add this support in needs
determining, it's not clear how to do so.
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
- Improved documentation for using declarations.
- Issue new warning WARN_LANG_USING_NAME_DIFFERENT when there
is a conflict in the target language name to be used when
introducing a method via a using declaration. Previously
the method was silently ignored. Issue #1840. Issue #655.
