Since the switch to wrapping classes using PHP's C API, we now
internally need to be able to tell if a PHP object is of or derived
from a class that is wrapped by SWIG so we know if we can offset the
zend_object pointer to get to the swig_object_wrapper. If we try to
do this to an object which isn't wrapped by SWIG then we invoke C/C++
undefined behaviour (and typically get a segmentation fault).
This check is implemented by having a SWIG\wrapped empty interface which
we make all SWIG-wrapped classes implement simply so we can test for it
to detect such classes.
Fixes#2125
As discussed and agreed in #1629, it's become hard to test with Perl
5.6 or earlier, such old versions are no longer in active use, and
4.1.0 is an appropriate time to make such a change.
I've dropped the compatibility code that was obvious to me, but there's
probably more that can be cleaned up now.
Fix access to C++ static member functions using Python class
staticmethod syntax, such as Klass.memberfunction instead of
Klass_memberfunction, when using -fastproxy and -builtin in
combination with %callback.
The docstring containing the callback pointers were not being patched
during module initialisation.
Accept keyword arguments accessing C++ static member functions when
using -builtin and kwargs feature and Python class staticmethod syntax.
The missing keyword argument support was only when using the
class staticmethod syntax, not when using the flat static method
syntax.
Previously the zend_class_entry for Foo was named SWIGTYPE_Foo_ce, but
this can collide in some cases - e.g. if there's a class named p_Foo
then its zend_class entry will be SWIGTYPE_p_Foo_ce, but that's the same
as the swig_type_info for a class named p_Foo_ce.
Do more initialisation at module load time.
Use a shared set of handlers for cases when the C/C++ object is
destroyed with free().
Most of the code in the free_obj and create_object handlers is the
same for every wrapped class so factor that out into common functions.
For example, `Char(foo)[0]` now works to get the first character
of DOH String `foo`.
Previously this gave a confusing error because it expanded to
`(char *) Data(foo)[0]` and the `[0]` binds more tightly
than the `(char *)`.
Fixes#2101. There are 3 related changes made here:
1. Move the SWIG_globals() singleton into pyrun from pyint so it
is visible to SWIG_Python_DestroyModule(). The static globals
varlink has been extracted out of the function so that it can
be set to NULL in SWIG_Python_DestroyModule(), which fixes the
issue described in #2101. (Now when the second interpreter
starts up, the Swig_Globals_global pointer will be NULL, so it
knows it has to create a new one.)
2. Remove a Py_DECREF on the globals varlink. The decrement is now
performed by DestroyModule(), so there's no need to do it in
SWIG_init().
3. Fixed similar issue with SWIG_Python_TypeCache().
This avoids conflicts between such functions, which are generated when
using %extend to add static methods to an existing class, and the actual
wrapper functions generated by the backend.
This shouldn't result in any user-visible changes.
No real changes, just move the test for "code" to the outer scope to
facilitate the upcoming changes.
This commit is best viewed ignoring whitespace-only changes.
`SWIG_ErrorCode()`, `SWIG_ErrorMsg()`, `SWIG_FAIL()` and `goto thrown;`
are no longer supported (these are really all internal implementation
details and none are documented aside from brief mentions in CHANGES
for the first three). I wasn't able to find any uses at least in FOSS
code via code search tools.
If you are using these:
Use `SWIG_PHP_Error(code,msg);` instead of `SWIG_ErrorCode(code);
SWIG_ErrorMsg(msg);` (which will throw a PHP exception in SWIG >= 4.1
and do the same as the individual calls in older SWIG).
`SWIG_FAIL();` and `goto thrown;` can typically be replaced with
`SWIG_fail;`. This will probably also work with older SWIG, but
please test with your wrappers if this is important to you.
Fixes#2014
Parameter type errors and some other cases in SWIG-generated wrappers
now throw a PHP exception, which is how PHP's native parameter handling
deals with similar situations.
See #2014, but not closing yet as there may be more cases to convert.
Most pre-defined interfaces are accessible via zend_class_entry*
variables declared in the PHP C API - we can use these to add
an interface at MINIT time (rather than having to wait until RINIT to
look up by name) by having a mapping from PHP interface name to them.
This will also be a little faster than looking up by name.
Closes#2013
