No meaningful progress to update CFFI to experimental status
has been made since CFFI was disabled in SWIG-4.0.0 as the first
stage to removal. This commit is the final stage to remove it.
See issue #1966 for an attempt at updating CFFI to experimental
status. Anyone wishing for SWIG to support CFFI again might
want to utilise this work.
This has only been present for backward compatibility since 2006
and now has the value 0 so doesn't do anything, so don't use it
as an example of a flag in the docs.
Such as:
class X final {};
This no longer gives a syntax error.
This change has introduced one more shift-reduce conflict in the parser.
with a conflict with a C style variable declaration with name final:
class X final;
resulting in a syntax error (for C++ not C). This is an an unusual style
for C++ code and more typical declarations do work:
X final;
Closes#672
Until now SWIG quietly ignored such errors unless -Wextra (or -Wall
which implies -Wextra) was passed, but this is unhelpful as it hides
problems. To illustrate this point, enabling this warning by
default revealled a typo in the preproc_defined.i testcase in
SWIG's own testsuite.
If you really don't want to see this warning, you can suppress it
with command line option -w202 or by using this in your interface
file:
%warnfilter(SWIGWARN_PP_EVALUATION);
Both will work with older versions of SWIG too.
Fixes#1465Fixes#2389
Ensure that SWIG_VERSION is defined both at SWIG-time and in the
generated C/C++ wrapper code (it was only defined in the wrapper
for some target languages previously).
SWIGGO and SWIGJAVASCRIPT are now defined in the generated wrappers
to match behaviour for all other target languages.
Stop defining SWIGVERSION in the wrapper. This only happened as a
side-effect of how SWIG_VERSION was defined but was never documented and
is redundant.
The new testcase also checks that SWIG is defined at SWIG-time but not
in the generated wrapper, and that exactly one of a list of
target-language specific macros is defined.
Fixes#1050
Octave has more operators than C++. These operators can be overloaded for
the type swig_ref using the standard Octave Object Oriented Programming mechanism.
This is now added to the documentation.
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
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.
This is a long-standing limitation, but only seems to have been reported
once back in 2004.
Nobody's cared enough to address it in 18 years, but we can at least
document it in the manual rather than only in a source code comment in
Source/Swig/symbol.c.
Addresses https://sourceforge.net/p/swig/bugs/429/
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
* unique_ptr-inputs:
std::unique_ptr std::auto_ptr tidyup
Add support for std::auto_ptr inputs
Cosmetic formatting and doc updates in std_unique_ptr.i files
Add Perl support for std::unique_ptr inputs
Add Ruby support for std::unique_ptr inputs
Add Python support for std::unique_ptr inputs
Add C# support std::unique_ptr inputs
Java unique_ptr test ownership enhancement to test
Java unique_ptr enhance test for double release
SWIGTYPE && input typemaps now assume object has been moved
Add Java support for std::unique<T> for input parameters.
Closes#692
Conflicts:
CHANGES.current
Avoid using reserved identifiers such as `_DOHINT_H` (fixes#1989),
fix cases where the name doesn't match the filename, and make the naming
more consistent and less likely to collide with include guards in other
headers.
The XML target language support is not in good shape and is likely to be
removed unless somebody steps up to bring it up to the expected standard
(it fails to even meet the criteria for "Experimental" currently).
Closes#2213
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.
