Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
Clean up to disable target languages that have been neglected/not functional.
Target language be fully deleted in SWIG 4.1 unless a new maintainer brings
it up to an acceptable status (experimental or supported).
Issue #1447
* ahnolds-autodoc:
Apparently nicely lining things up violates pep8, so don't try
Don't use bool in the generated files for C compatability
Properly handle destructors as methods for autodoc and fix some stray newlines
Fixing a bug where the cached doxygen docstring could be deleted while still in use, causing swig to segfault
Fixing docstrings for variables and static functions for consistency
Fixes so that fastproxy and autodoc work correctly with both low-level C API and high-level Python Shadow API
Updating the changelog
Also check documentation on the low-level API
Fix a bug where anonymous arguments were misnumbered when used in constructors
Fixing python docstring handling for -fastproxy
Conflicts:
CHANGES.current
SWIG now requires a target language to be specified instead of
defaulting to wrapping for Tcl. Specifying swig --help without
a target language now just shows the generic help. The -nolang
option has been removed.
These remaining warnings are due to the design of Python's C API,
so suppress them by casting via void(*)(void) (which GCC documents
as the way to suppress this warning).
Closes#1259.
The swig.gdb file provides the swigprint and locswigprint user-defined
commands which stopped working somewhere around gdb 8.0 - 8.2.
```
(gdb) swigprint n
Undefined command: "Printf". Try "help".
(gdb) locswigprint n
Undefined command: "Printf". Try "help".
(gdb)
```
I couldn't find any mention of gdb's Printf, but replacing Printf with
printf works and is documented at
https://sourceware.org/gdb/download/onlinedocs/gdb/Output.html#Output
Fixes issue #1420
[skip ci]
- Static method wrappers were using the 'fastproxy' approach by default.
This is inconsistent with instance method wrappers. The fastproxy approach
is now turned off by default to be consistent with instance methods.
Static method wrappers can now also be controlled using the -fastproxy and
-olddefs options.
Example:
struct Klass {
static int statmethod(int a = 2);
};
generates:
class Klass(object):
...
@staticmethod
def statmethod(a=2):
return _example.Klass_statmethod(a)
instead of:
class Klass(object):
...
statmethod = staticmethod(_example.Klass_statmethod)
- Modernise wrappers for static methods to use decorator syntax - @staticmethod.
- Add missing runtime test for static class methods and using the actual
class method.
* ZackerySpytz-OCaml_int64_t:
Add changes entry for fixing OCaml int64_t compile problem
Fix OCaml version detection if caml/version.h is not available
[OCaml] Use int64_t instead of int64 for OCaml versions >= 4.03.0
Conflicts:
CHANGES.current
Test added to check fixes for:
- Issue #948 and issue #1019 and issue #1273 - raw string delimiters
not being stripped off
- Issue #538 - Ruby support for "docstring" feature
The docstring was not encapsulated within /* */ comments.
The implementation had code for autodoc strings being either single or
multi-line and then adding extra newlines. However, in practice only multi-line
autodoc string are ever generated, so this bit of code handling was removed.
The docstring feature does not attempt to add newlines depending on the
existence of newlines in the docstring.
Closes#538
Global functions previously generated two definitions, eg:
def foo():
return _example.foo()
foo = _example.foo
The first definition is replaced by the second definition and so the second definition
is the one used when the method is actually called. Now just the first definition is
generated by default and if the -fastproxy command line option is used, just the second
definition is generated. The second definition is faster as it avoids the proxy Python
method as it calls the low-level C wrapper directly. Using both -fastproxy and -olddefs
command line options will restore the previously generated code as it will generate both
method definitions.
With this change, the wrappers for global C/C++ functions and C++ class methods now work
in the same way wrt to generating just a proxy method by default and control via
-fastproxy/-olddefs options.
Closes#639.
* java-director-thread-name:
Add changes entry for setting Java thread name
Increased Java thread name size.
Java directors - more generic thread name setting
Use prctl method to get thread names, which is available on all NDK versions
Actually, pthread_getname_np is only available in recent versions of Android (API level >= 26).
Set thread name when attaching to Android JVM in SWIG Java director
* python-obfuscated-import-errors:
More Python module loading simplification
Simpler Python module loading
The Python module import logic has changed to stop obfuscating real ImportError problems.
Only one import of the low-level C/C++ module from the pure Python module is
attempted now. Previously a second import of the low-level C/C++ module was attempted
after an ImportError occurred and was done to support 'split modules'. A 'split module' is
a configuration where the pure Python module is a module within a Python package and the
low-level C/C++ module is a global Python module. Now a 'split module' configuration is
no longer supported by default. This configuration can be supported with a simple
customization, such as:
%module(package="mypackage", moduleimport="import $module") foo
or if using -builtin:
%module(package="mypackage", moduleimport="from $module import *") foo
instead of
%module(package="mypackage") foo
See the updated Python chapter titled "Location of modules" in the documentation.
Closes#848#1343
closes#1374
* enhance testing around multiple return values
Examples/test-suite/perl5/scilab_multivalue_runme.pl fails in
perl-5.28.1 compiled with -DDEBUGING without the typemap updates
* repair EXTEND() handling in typemaps
* Use PL_sv_undef for VOID_Object
This examples tests the SWIG generated module being placed into a directory and
then renamed __init__.py to convert the module into a package. This ability
stopped working in swig-3.0.9. However, only Python 2.7 or 3.3 and later work. If
Python 3.2 support is needed, use moduleimport in %module to customise the import
code.
Issue #1282
* adr26-master:
Cleanup accessing/decref of globals, to avoid code bloat in init function.
Fix ISOC build errors.
Fix unused variable warning.
#1360: Leak of SWIG var link object
Conflicts:
CHANGES.current
When using -builtin, the two step C-extension module import is now
one step and the wrapped API is only available once and not in an underlying
module attribute like it is without -builtin. To understand this, consider a
module named 'example' (using: %module example). The C-extension is compiled into
a Python module called '_example' and a pure Python module provides the actual
API from the module called 'example'. It was previously possible to additionally
access the API from the module attribute 'example._example'. The latter was an
implementation detail and is no longer available. It shouldn't have been used, but
if necessary it can be resurrected using the moduleimport attribute described in the
Python chapter of the documentation. If both modules are provided in a Python
package, try:
%module(moduleimport="from . import _example\nfrom ._example import *") example
or more generically:
%module(moduleimport="from . import $module\nfrom .$module import *") example
and if both are provided as global modules, try:
%module(moduleimport="import _example\nfrom _example import *") example
or more generically:
%module(moduleimport="import $module\nfrom $module import *") example
The module import code shown will appear in the example.py file.
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.
