Includes the majority of patch #1484.
Excludes changes in typepass.cxx for specializations which have no effect
on the duplicate_class_name_in_ns testcase, nor the rest of the test-suite.
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
On 32-bit platforms -2147483648 is a PHP float (rather than PHP int on
64-bit platforms) so only check equivalence rather than strict equality.
Fixes#2360
Recent change to SwigValueWrapper required the <utility> header.
Included headers should be after the include of the language
specific header files (which go into the earlier runtime section).
Testcase required -Winit-list-lifetime warning suppression change
for Perl which somehow lost the warning suppression when put
into the %begin section.
SWIG has always marshalled the null matrix into a NULL pointer; this remains
and now we have consistency in representing a NULL pointer.
This is a pre-requisite for a pending commit to fully support std::unique_ptr.
SWIG now converts a C/C++ NULL pointer into a null value by calling
scheme_make_null(), so that scheme's null? is true for a NULL C/C++
pointer value.
Consistency with Guile and needed for a pending commit for handling
NULL and std::unique_ptr.
Particularly when using virtual inheritance as the pointers weren't
correctly upcast from derived class to base class when stored in the
base's proxy class.
Fixes commented out test code in cpp11_std_unique_ptr_runme
and li_std_auto_ptr_runme D tests.
I don't think any valid C program can contain `<=>` in a tokenisable
context, but it's more helpful to fail with a syntax error at SWIG
parse time and not potentially generate C code trying to use `<=>` in
an expression which then fails at compile time.
Remove some erroneously added brackets_increment() calls.
Reject <=> in preprocessor expressions with a clear error message (it
seems it isn't supported here - clang and gcc don't at least).
The type returned by `<=>` is not `bool`. We pretend it's
`int` for now, which should work for how it's likely to be used
in constant expressions.
Fixes#1622