Activity for SWIG
-
Olly Betts posted a comment on ticket #1095
This patch fixes the example here, but seems a bit of a hack as it just allows anything to be passed for this parameter, but with the lowest typecheck precedence. Ideally we should actually check for what's accepted her, though the in typemap allows anything so maybe that's actually correct: diff --git a/Lib/lua/lua_fnptr.i b/Lib/lua/lua_fnptr.i index b4c663c5..8e67d8fb 100644 --- a/Lib/lua/lua_fnptr.i +++ b/Lib/lua/lua_fnptr.i @@ -115,6 +115,9 @@ void swiglua_ref_get(SWIGLUA_REF* pref){ %} +%typemap(typecheck,...
-
William Fulton modified ticket #884
[csharp] getCPtr should use object.ReferenceEquals
-
I'm not sure it will be easy to keep the code based maintained to always cover this corner case. The relevant typemaps can be easily changed by the user to use ReferenceEquals instead and so I'm closing as won't change. I can't there being a runtime overhead when there is no operator== overload.
-
SWIG-4.2.1 released
-
SWIG released /swigwin/swigwin-4.2.1/swigwin-4.2.1.zip
-
-
-
-
Looks like https://github.com/swig/swig/issues/197 may be the same issue.
-
Still reproducible with current git master. Also I came up with a much simpler reproducer: %module x %inline %{ typedef enum { BAZ1 } baz; void enumbugexample( baz const & ) { } %} Then: $ swig -c++ -python simplified.i $ grep 'enum baz' simplified_wrap.cxx enumbugexample((enum baz const &)*arg1); static swig_type_info _swigt__p_baz = {"_p_baz", "baz *|enum baz *", 0, 0, (void*)0, 0}; The const & seems to be needed. I notice the type info entry includes enum baz * which seems wrong too.
-
I noticed the problem reported here is actually documented in the manual: https://www.swig.org/Doc4.2/SWIGPlus.html#SWIGPlus_namespaces Because namespaces are flattened, it is possible for symbols defined in different namespaces to generate a name conflict in the target language. For example: namespace A { void foo(int); } namespace B { void foo(double); } When this conflict occurs, you will get an error message that resembles this: example.i:26. Error. 'foo' is multiply defined in the generated...
-
Still present in git shortly after 4.2.0. It also seems to fail even if %nspace N; is used with a target language with %nspace support.
-
Still reproducible with git master shortly after 4.2.0. Looking at this afresh, the two delete_v calls are OK as those are for the temporary v(1.1.1) and v(2,2,2) objects passed to the comp constructor. The essential problem here is that comp_a_get returns a Python v object which wraps a pointer to the C++ v a inside the temporary comp object, but then delete_comp is called before we call v_x_get on that v. For this to work it seems either a reference to comp needs to be kept by the v returned by...
-
Still happens with current git master (shortly after SWIG 4.2.0) except the error is now a TypeError: TypeError: Wrong number or type of arguments for overloaded function 'IntVec___setitem__'.
-
Still present in current git master (shortly after 4.2.0). SWIG now handles both these cases: void f(double param = i.d()); void f(double param = Outer::d()); However the case reported here with both a namespace and an object is still not handled.
-
Still present in current git master (shortly after 4.2.0). SWIG now handles both these cases, but still not the case reported here with both a namespace and an object: void f(double param = i.d()); ``` void f(double param = Outer::d()); ```
-
Identifier warning for friend methods in a namespace
-
Fixed in a6ab9145115aa124ff9c98e2b3c39fde9f205760
-
Namespace breaks %ignore with unbound C++ operator<<
-
Fixed by a6ab9145115aa124ff9c98e2b3c39fde9f205760. All 6 of the %ignore directives shown now work.
-
SWIG-4.2.0 released
-
SWIG-4.2.0 released
-
SWIG-4.2.0 released
-
-
-
-
-
-
-
-
-
-
-
-
-
Problems with long/jlong and int64_t on 64-bit platforms
-
This recent commit (which will be in SWIG 4.2.0) looks like it addresses the remaining points here: commit 7bba06b03ef4529c542c3cf8364c382027aae000 Author: William S Fulton <wsf@fultondesigns.co.uk> Date: Wed Sep 27 07:46:53 2023 +0100 Java - SWIGWORDSIZE64 for long type Defining SWIGWORDSIZE64 now applies the (unsigned) long long typemaps to (unsigned) long for a better match on systems where long is 64-bits. Although size_t typemaps are now applied from the int typemaps instead of the long typemaps,...
-
Reproducible with git master 29367b31c8202c5cbe72e05927d77004636d6af9. Running with -debug-module 1 then -debug-module 2 it seems this happens somewhere in between those two stages: +++ class - 0x7f9380f74810 ---------------------------------------- | allows_typedef - "1" | firstChild - 0x7f9380f74950 | kind - "class" | lastChild - 0x7f9380f74d70 | module - 0x7f9380f73b30 | name - "Parser::Parser" | parentNode - 0x7f9380f73c50 | previousSibling - 0x7f9380f74670 | sym:name - "Parser" | sym:overname...
-
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/how-to-define-value-equality-for-a-type seems to be the current version of the link wsfulton gave above.
-
where does that int come from? Oh, that's my fault - I was experimenting with the testcase and had added an int parameter before the ...! The other issues still seem to be the case with current git master.
-
Still fails to parse with current git master.
-
Retesting with current git master I spotted a problem with how I was building the shared library - the reproducer still fails as given, but s/::ns/ns/g makes it work. So my "things seem to have got worse" above is bogus.
-
I think that given this feature was removed 18 years ago we should just update the documentation to match reality. Reinstating these typemaps looks hard as they seem to use some magic via a parse typemap attribute which there's no longer any code to handle, and I can't see where it used to be handle, or any documentation as to what it did: %typemap(in,parse="I") int CONSTANT, unsigned int CONSTANT ""; I've remove the documentation in 10bab22248327642133fcb94a7a7c1eb5e041ab8. If someone wants to reinstate...
-
[tcl] Constants and enums - apply rule not working
-
C++ memory leak of temporaries on exception
-
I fixed this same issue for Lua in 9ab9c716239d2855bdd6c0771e2e980c0767fb57, and https://github.com/swig/swig/issues/1981 is the same but for Go. There's a testcase exception_memory_leak for it so writing a _runme.pl for that would provide a regression test.
-
Swig, perl5 and union
-
The union variable name is called intRep and is an anonymous union, that is, it does not have any type name. It is thus not possible to create a type outside of Object to assign to intRep. Consider a small change to give the union a type name, say IntRepType as follows: typedef struct Object { int objtype; union IntRepType { int ivalue; double dvalue; char *strvalue; void *ptrvalue; } intRep; } Object; void tester() { /* approach (1) */ obj.intRep.dvalue = 1.23; /* approach (2) */ union IntRepType...
-
c++ private assignment operator not obeyed for arrays
-
Fixed in https://github.com/swig/swig/commit/650aad82ede59abe1a9355c274e213d33ae9d543.
-
swig tries to call private constructor
-
Fixed in https://github.com/swig/swig/commit/f11bffcb1993eb5435b093f2641f857ccb674a77.
-
Lifecycle of pointers to 'concrete' sub-objects (C#-binding patch included)
-
It seems like the case which triggered this report was probably really due to incorrect code elsewhere. However it seems to me that when SWIG is checking if the object is null in such cases it would still be better for it do (object)obj == null (and similarly for some obj != null tests I see which the patch here doesn't address) as it really does want an exact null check and it isn't necessary to be calling an overloaded == in this case. Usually what SWIG currently does just incurs a small but avoidable...
-
[csharp] getCPtr should use object.ReferenceEquals
-
[csharp] getCPtr should use object.ReferenceEquals
-
[ruby] mixed case module names not handled correctly
-
https://github.com/rubocop/ruby-style-guide#snake-case-files adds evidence that what SWIG calls the "init name" ought to be lower case. According to that it perhaps ought to be open_babel here rather than openbabel for %module OpenBabel - SWIG does have CamelCase to snake_case conversion code so we could easily do that, and there's always -initname openbabel if that's what you really want. I think this should just apply to the auto-generated default, and an explicit -initname OpenBabel should allow...
-
I retested as there have been some using fixes recently and the cause of this looks to be using ClassC::MyFunc; in ClassD, but this is still reproducible with current git master (2e1506c1896f90456e5b3092ba7c7200c1b1e2e1): $ ../preinst-swig -c++ -java example.i $ grep -A3 'public double MyFunc(ClassX p)' ClassD.java public double MyFunc(ClassX p) { return exampleJNI.ClassD_MyFunc__SWIG_1(swigCPtr, this, ClassX.getCPtr(p), p); } public double MyFunc(ClassX p) { return exampleJNI.ClassD_MyFunc__SWIG_2(swigCPtr,...
-
Current git master (2e1506c1896f90456e5b3092ba7c7200c1b1e2e1) now emits two errors, but then still segfaults (with both the original and with = 0 removed to make it valid C++): ../preinst-swig -c++ -python test.i test.i:2: Warning 323: Recursive scope inheritance of 'A<(char,0)>'. test.i:2: Warning 323: Recursive scope inheritance of 'A< char,0 >'. Segmentation fault (core dumped) The crash is due to an infinite recursion, which this patch fixes: diff --git a/Source/Modules/allocate.cxx b/Source/Modules/allocate.cxx...
-
[ruby] Segfault with "using" declaration with templates
-
This is fixed in current git master which generates code with Derived.fun in both chunks of code shown above. git bisect shows the commit fixing it as being: commit 49e60c7d5617f482026e8585d02ddc3f8244e2e5 Author: William S Fulton <wsf@fultondesigns.co.uk> Date: Sat Jun 24 11:43:15 2023 +0100 Fix directors and allprotected mode and using declarations. Fixes recently introduced seg fault, but this has never worked properly. Closes #2616 CHANGES.current | 5 ++++ Examples/test-suite/allprotected.i |...
-
'using' directive may prevent constructor wrapping
-
Fixed in 93732bb19562534c81c537b8a83e38451556415c for swig-4.2.0.
-
Great - 2ff9da0ce625eabf0dde3ffeaec075eba2c733a8 was the exact commit fixing this for the record.
-
template constructor of template class not recognized
-
Corrected testcase: %inline %{ template <typename T, typename U> struct MyClass { template<typename P> // MyClass<T,D>(P p) MyClass<T,U>(P p) { } }; %} %template(MyClassImpl) MyClass<int, int>; Note that MyClass<T,U> is not valid syntax from C++20 onwards, but SWIG continues to support it. The warning no longer appears in master, so this issue is fixed for swig-4.2.0.
-
Your code above is invalid. However, if it is corrected: %inline %{ class Base { public: virtual void f(int n) = 0; void f(double another_representation_of_n) { } }; //And a derived class class Derived : public Base { public: Derived() {} using Base::f; virtual void f(int n) {} }; %} Then Derived does not have a constructor and this is incorrect. There is an easy workaround for now and that is to swap two lines around as such: virtual void f(int n) {} using Base::f;
-
-copyctor bug?!
-
This bug is a problem with non-const copy constructors in an inheritance chain. SWIG always assumed the implicit copy constructor was defined with a const reference parameter. For reference, https://en.cppreference.com/w/cpp/language/copy_constructor outlines nicely when the implicit constructor uses a const or non-const reference parameter. Fixed in 74e1deef6bd86135ee2a5f007b6347202813d143.
-
Reproduced with 5e1a37c6c562b7cb62c62e439c5b6b647e6d6df5 (retested because that commit fixes a copyctor bug).
-
Reproduced with 595009cf2ff952d963a663113e82b032c4fa770f.
-
I've opened a PR with that change: https://github.com/swig/swig/pull/2644
-
There have been some allprotected fixes recently, but this is still reproducible.
-
There have been some allprotected fixes recently, but this is still reproducible.
-
Andriy Gerasika posted a comment on ticket #39
I am interested in this feature -- can you please send the changes, so I can integrate these into most recent version of Swig on Github? Thank You
-
Looks like https://sourceforge.net/p/swig/bugs/879/ is closely related and probably the same issue.
-
Still reproducible. Looks like https://sourceforge.net/p/swig/bugs/1250/ is closely related and probably the same issue.
-
I've opened a PR with this patch to try to move things forwards: https://github.com/swig/swig/pull/2636
-
https://github.com/swig/swig/issues/1171 may be related.
-
Wrapping Intel IPP headers generates assertion.
-
I failed to fully revert my second attempt, and actually left the first fix in place, just without the testcase, so this really was fixed in SWIG 4.1.0 (and I've just confirmed that the original full example can be processed successfully with currently SWIG git master).
-
Fixed on git master by https://github.com/swig/swig/commit/26dfe3394810a72e85c4c52ee568ff44cfbcac76. Fix should be in 4.2.0. (https://github.com/swig/swig/issues/1881 seems to actually be slightly different as that's not fixed by this change)
-
%ignore not utilized for xml output
-
In https://github.com/swig/swig/issues/2213 @wsfulton said about -xml: XML isn't really a target language at all and it never will be! It's not much different to the -debug-top debug option which dumps internal parse tree information. The main difference is the format of the output. The Foo class appears in the output of swig -c++ -python -debug-top 1 Examples/test-suite/class_ignore.i (and similarly for -debug-top 2 to -debug-top 4) . So while -xml is essentially undocumented, I think this is working...
-
It's a two dimension array of function pointers if I've understood it correctly, though I'm not certain I have. Actually, I think it's a two dimensional array of pointers to int. Still reproducible. Possibly related to https://github.com/swig/swig/issues/142
-
SWIG tries to wrap va_list dumbly
-
Reflecting on this, I think the now-documented approach mentioned above is a reasonable solution. Also APIs I've seen which have a function taking va_list often also provide a corresponding varargs function too, and in such cases attempting to automatically wrap the va_list one by generating a varargs function and wrapping it would be actively unhelpful. It'd be nicer to not generate wrapper code which doesn't compile for functions taking va_list, but I don't think we have a way to avoid wrapping...
-
Ticket moved from /p/swig/feature-requests/93/
-
Ticket moved from /p/swig/feature-requests/62/
-
Parse error on two parameter template template argument
-
Duplicate of https://github.com/swig/swig/issues/1603 which is now fixed
-
partial specialization not recognized
-
Duplicate of https://github.com/swig/swig/issues/1300 which is now fixed.
-
I think this is probably essentially the same as https://github.com/swig/swig/issues/2089
-
(Though the testcase needs tweaking slightly to actually define the enum (e.g. enum TestEnum { TESTENUM };) or else compilation gives an error: test_wrap.cxx:3159:8: error: use of enum ‘TestEnum’ without previous declaration 3159 | enum TestEnum; | ^~~~~~~~ with that adjustment the generated wrapper fails to compile with: g++ `python3-config --cflags` -fPIC -c test_wrap.cxx -o test_wrap.o test_wrap.cxx: In function ‘PyObject* _wrap_new_VecTestNum(PyObject*, PyObject*)’: test_wrap.cxx:3327:38: error:...
-
(Though the testcase needs tweaking slightly to actually define the enum (e.g. enum TestEnum { TESTENUM };) or else compilation gives an error: test_wrap.cxx:3159:8: error: use of enum ‘TestEnum’ without previous declaration 3159 | enum TestEnum; | ^~~~~~~~ with that adjustment the generated wrapper fails to compile with: g++ `python3-config --cflags` -fPIC -c test_wrap.cxx -o test_wrap.o test_wrap.cxx: In function ‘PyObject* _wrap_new_VecTestNum(PyObject*, PyObject*)’: test_wrap.cxx:3327:38: error:...
-
Still reproduces with current git master (b18b75369cd4b2795abad1283629b13a62630b58)