swig / swig Goto Github PK

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.

Home Page: http://www.swig.org

License: Other

C 19.48% Makefile 0.82% Shell 0.64% HTML 0.10% Python 0.34% C++ 43.54% Scheme 0.04% OCaml 0.25% Ruby 0.01% Yacc 4.80% M4 2.68% GDB 0.02% Perl 0.01% SWIG 27.15% CMake 0.11%

swig's Introduction

SWIG (Simplified Wrapper and Interface Generator)

Tagline: SWIG is a compiler that integrates C and C++ with languages
         including Perl, Python, Tcl, Ruby, PHP, Java, C#, D, Go, Lua,
         Octave, R, Scheme (Guile, MzScheme/Racket), Scilab, Ocaml.
         SWIG can also export its parse tree into XML.

SWIG reads annotated C/C++ header files and creates wrapper code (glue
code) in order to make the corresponding C/C++ libraries available to
the listed languages, or to extend C/C++ programs with a scripting
language.

Up-to-date SWIG related information can be found at

        https://www.swig.org

A SWIG FAQ and other hints can be found on the SWIG Wiki:

        https://github.com/swig/swig/wiki

License
=======
Please see the LICENSE file for details of the SWIG license. For
further insight into the license including the license of SWIG's
output code, please visit

        https://www.swig.org/legal.html

Release Notes
=============
Please see the CHANGES.current file for a detailed list of bug fixes and
new features for the current release. The CHANGES file contains bug fixes
and new features for older versions. A summary of changes in each release
can be found in the RELEASENOTES file.

Documentation
=============
The Doc/Manual directory contains the most recent set of updated
documentation for this release. The documentation is available in
three different formats, each of which contains identical content.
These format are, pdf (Doc/Manual/SWIGDocumentation.pdf), single
page html (Doc/Manual/SWIGDocumentation.html) or multiple page html
(other files in Doc/Manual). Please select your chosen format and
copy/install to wherever takes your fancy.

There is some technical developer documentation available in the
Doc/Devel subdirectory.  This is not necessarily up-to-date, but it
has some information on SWIG internals.

Documentation is also online at https://www.swig.org/doc.html.

Backwards Compatibility
=======================
The developers strive their best to preserve backwards compatibility
between releases, but this is not always possible as the overriding
aim is to provide the best wrapping experience. Where backwards
compatibility is known to be broken, it is clearly marked as an
incompatibility in the CHANGES and CHANGES.current files.

See the documentation for details of the SWIG_VERSION preprocessor
symbol if you have backward compatibility issues and need to use more
than one version of SWIG.

Installation
============
Please read the Doc/Manual/Preface.html#Preface_installation for
full installation instructions for Windows, Unix and Mac OS X
using the release tarball/zip file. The INSTALL file has generic
build and installation instructions for Unix users.
Users wishing to build and install code from Github should
visit https://swig.org/svn.html to obtain the more detailed
instructions required for building code obtained from Github - extra
steps are required compared to building from the release tarball.

Testing
=======
The typical 'make -k check' can be performed on Unix operating systems.
Please read Doc/Manual/Preface.html#Preface_testing for details.

Examples
========
The Examples directory contains a variety of examples of using SWIG
and it has some browsable documentation.  Simply point your browser to
the file "Example/index.html".

The Examples directory also includes Visual C++ project 6 (.dsp) files for
building some of the examples on Windows. Later versions of Visual Studio
will convert these old style project files into a current solution file.

Known Issues
============
There are minor known bugs, details of which are in the bug tracker, see
https://www.swig.org/bugs.html.

Troubleshooting
===============
In order to operate correctly, SWIG relies upon a set of library
files.  If after building SWIG, you get error messages like this,

    $ swig foo.i
    :1. Unable to find 'swig.swg'
    :3. Unable to find 'tcl8.swg'

it means that SWIG has either been incorrectly configured or
installed.  To fix this:

    1.  Make sure you remembered to do a 'make install' and that
        the installation actually worked.  Make sure you have
        write permission on the install directory.

    2.  If that doesn't work, type 'swig -swiglib' to find out
        where SWIG thinks its library is located.

    3.  If the location is not where you expect, perhaps
        you supplied a bad option to configure.  Use
        ./configure --prefix=pathname to set the SWIG install
        location.   Also, make sure you don't include a shell
        escape character such as ~ when you specify the path.

    4.  The SWIG library can be changed by setting the SWIG_LIB
        environment variable.  However, you really shouldn't
        have to do this.

If you are having other troubles, you might look at the SWIG Wiki at
https://github.com/swig/swig/wiki.

Participate!
============
Please report any errors and submit patches (if possible)!  We only
have access to a limited variety of hardware (Linux, Solaris, OS-X,
and Windows). All contributions help.

If you would like to join the SWIG development team or contribute a
language module to the distribution, please contact the swig-devel
mailing list, details at https://www.swig.org/mail.html.


 -- The SWIG Maintainers

swig's People

Contributors

Stargazers

Watchers

Forkers

kkaempf brantkyser blowekamp malaterre richardbeare ptomulik markok314 robertluptonthegood a9s6 marvingreenberg wkalinin fabiencastan cdelbaere tristan0x rmichon sonney2k kmhtoo azynheira maginatics geraldwodni kingpotato gjanssens yminer jo3w4rd wsfulton aptech tjensen dinesh-ramakrishnan tcelvis yuexiae jlopez mbancroft trel openflex paleozogt baibaiwei yangrongwei tj64 v-for-vandal isislovecruft smarchetto eddotman andrew-simmons tsahlin darthgandalf kelvin-ng giapdangle davidlongest vigsterkr akihiroy artclarke rortian infosia vadz snogglethorpe medhachhillar smikes lyrebirdsw nixz oztc jaeandersson conght tlby eehlers jleveque vmiklos micha137 diorcety qinchang wxiang7 itawswati ronsaldo x2nie cocos hfalcic cdunham ewmailing kimcm coinpayee deepak1556 bloff fgaudet johnnydeamer torus greenavocadoes khanhqh2008i pingany sebgod rm374 kokakiwi asherbond farre coleb armstrongj manukothari kesmit13 feverq yuvalk gpetrou hunterchen

swig's Issues

Directors for const methods

Creating a director wrapper for classes with methods marked as const:

class Base {
protected:
  virtual bool GetBoolean() const = 0;
}

results in an incorrect "wrap:action" in the wrapped method call. The cast is inserted as (memberfunctionHandler:value const *)darg and it should be (SwigDirector_Base const *)darg.

I tracked this down to DirectorClassName being incorrect at https://github.com/swig/swig/blob/master/Source/Modules/lang.cxx#L1253. I'm not sure how DirectorClassName should be set properly, but I was able to resolve the code generation by calling directorClassName with the methods parent node by changing:

director_type = Copy(DirectorClassName);

to:

director_type = Copy(directorClassName(Getattr(n, "parentNode")));

I am using the parent node because the method node does not have an appropriate "nspace" parameter and will not generate a correct value when using namespaces. Also, this may only be happening for protected methods, but I'm not sure.

Bad interaction of %ignore with %rename for template classes methods

This is a strange bug which is probably best shown with an example:

$ cat -n ut.i
     1  %module ut
     2
     3  %ignore *::Foo;
     4  %rename("%s") T::Foo;
     5  //%rename("%s") T<int>::Foo;
     6
     7  %inline %{
     8    template <typename V> struct T {
     9        V Foo();
    10        V Bar();
    11    };
    12
    13    struct S {
    14      void Foo();
    15      void Bar();
    16    };
    17  %}
    18  %template(IntT) T<int>;
$ swig -csharp -c++ -o wrap_ut_csharp.cpp ut.i
$ fgrep Foo *.cs || echo "Foo not exported"
Foo not exported

Uncommenting line 5 makes it work as expected, i.e. T::Foo() is exported. But both line 5 and line 4 are needed, if either one is omitted, Foo() is ignored.

Also notice that this is related to %ignore, without it, i.e. if we use %rename(Baz) on Foo(), line 4 on its own works just fine.

This was first reported in this thread

php director_basic example seg fault

The director_basic example seg faults on Travis OSX - https://travis-ci.org/swig/swig/builds/23270178. I can replicate it on Mountain Lion...

MountainLion:php william$ make director_basic.cpptest 
if [ -f ./director_basic_runme.php ]; then echo "checking php testcase director_basic (with run test)" ; else echo "checking php testcase director_basic" ; fi;
checking php testcase director_basic (with run test)
make -f ../../../Examples/Makefile CXXSRCS="" SWIG_LIB="../../../Lib" SWIG=" ../../../preinst-swig" INCLUDES="-I../../../Examples/test-suite" SWIGOPT="-outcurrentdir -I../../../Examples/test-suite" NOLINK=true TARGET="director_basic" INTERFACEDIR="../../../Examples/test-suite/" INTERFACE="director_basic.i" php_cpp
../../../preinst-swig -php -cppext cxx -c++ -outcurrentdir -I../../../Examples/test-suite ../../../Examples/test-suite/director_basic.i
g++ -c  -I/usr/local/include    director_basic_wrap.cxx -I../../../Examples/test-suite -I/usr/local/Cellar/php54/5.4.27/include/php -I/usr/local/Cellar/php54/5.4.27/include/php/main -
I/usr/local/Cellar/php54/5.4.27/include/php/TSRM -I/usr/local/Cellar/php54/5.4.27/include/php/Zend -I/usr/local/Cellar/php54/5.4.27/include/php/ext -I/usr/local/Cellar/php54/5.4.27/include/php/ext/date/lib
g++ -bundle -undefined suppress -flat_namespace -I/usr/local/include    director_basic_wrap.o   -o director_basic.so
if [ -f ./director_basic_runme.php ]; then make -f ../../../Examples/Makefile PHP_SCRIPT=./director_basic_runme.php RUNTOOL="" php_run; elif [ -f ./director_basic.php -a ! -f ../../../Examples/test-suite/director_basic.list ]; then make -f ../../../Examples/Makefile PHP_SCRIPT=./director_basic.php RUNTOOL="" php_run; fi
php -n -q -d extension_dir=. -d safe_mode=Off ./director_basic_runme.php 
make[1]: *** [php_run] Segmentation fault: 11
make: *** [director_basic.cpptest] Error 2

gdb stack trace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
0x00000001003b33b8 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST ()
(gdb) where
#0  0x00000001003b33b8 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST ()
#1  0x000000010038ef23 in ZEND_FETCH_OBJ_FUNC_ARG_SPEC_UNUSED_CONST_HANDLER ()
#2  0x000000010035f5af in execute ()
#3  0x000000010033323c in zend_call_function ()
#4  0x0000000100350831 in zend_call_method ()
#5  0x000000010035add6 in zend_std_call_getter ()
#6  0x000000010035aab1 in zend_std_read_property ()
#7  0x00000001003b2f09 in zend_fetch_property_address_read_helper_SPEC_CV_CONST ()
#8  0x00000001003868d2 in ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER ()
#9  0x000000010035f5af in execute ()
#10 0x000000010033323c in zend_call_function ()
#11 0x0000000100332a0a in call_user_function ()
#12 0x0000000101b459a4 in SwigDirector_MyClass::vmethod (this=0x101a75dc0, b={x = 3}) at director_basic_wrap.cxx:1658
#13 0x0000000101b4bb25 in MyClass::cmethod (this=0x101a75dc0, b=@0x101a795d0) at director_basic_wrap.cxx:1382
#14 0x0000000101b43d47 in _wrap_MyClass_cmethod (ht=2, return_value=0x101b94008, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at director_basic_wrap.cxx:2988
#15 0x00000001003a2a16 in zend_do_fcall_common_helper_SPEC ()
#16 0x000000010035f5af in execute ()
#17 0x000000010033e96c in zend_execute_scripts ()
#18 0x00000001002ed80b in php_execute_script ()
#19 0x00000001003c1e25 in do_cli ()
#20 0x00000001003c0ced in main ()

I don't think this a new problem as it also occurs with swig-2.0.12. php-5.3 is okay on this system though. Any suggestions for fixes or further debugging into I can supply from anyone familiar with the php api?

Typemap looking when using template and typedef

Imagine you put a typemap like this:
typemap(out) Namespace::A "Example";
Added to this Namespace::A is a typedef to Namespace::B

namespace Namespace {
typedef B A;
}

now use a vector of Namespace::A
%template(Namespace::A) std::vector<Namespace::A>;

There is an problem! For example in python for getitem function it will try the following typemap:
std::vector< Namespace::B >::value_type
then

Namespace::B

A correct behaviour should be

std::vector< Namespace::A >::value_type
Namespace::A
std::vector< Namespace::B >::value_type
Namespace::B

std::vector< Namespace::A >::value_type
std::vector< Namespace::B >::value_type
Namespace::A
Namespace::B

Forward declaration tests fail to build when using clang++ on OSX

The two tests template_using_directive_and_declaration_forward and using_directive_and_declaration_forward fail to build in the java test suite. The code and errors are shown below. This is for clang-500 on mavericks and clang-425 on mountain lion.

This seems to be a clang issue - this code builds fine on g++ 4.2 and 4.8. li_std_vector also has a build failure.

214: namespace Outer1 {
215:   namespace Space1 {
216:     template<typename T> class Thing1;
217:   }
218: }
219: using namespace Outer1::Space1;
220: using Outer1::Space1::Thing1;
221: template<typename T> class Thing1 {};
222: void useit1(Thing1<int> t) {}

clang++ -c -I/opt/local/include template_using_directive_and_declaration_forward_wrap.cxx -I../../../../Examples/test-suite -I"/System/Library/Frameworks/JavaVM.framework/Headers" -I"/System/Library/Frameworks/JavaVM.framework/Headers"
template_using_directive_and_declaration_forward_wrap.cxx:222:6: error: variable has incomplete type 'void'
void useit1(Thing1 t) {}
^
template_using_directive_and_declaration_forward_wrap.cxx:222:13: error: reference to 'Thing1' is ambiguous
void useit1(Thing1 t) {}
^
template_using_directive_and_declaration_forward_wrap.cxx:220:23: note: candidate found by name lookup is 'Thing1'
using Outer1::Space1::Thing1;
^
template_using_directive_and_declaration_forward_wrap.cxx:221:28: note: candidate found by name lookup is 'Thing1'
template class Thing1 {};
^

C++11 enum class scope issue

There are 3 different strong enums defined, like this:

enum class /* name */
{
    // ...
    Invalid,
    // ...
}

When using latest HEAD version of swig, I get following:

/[...]/MapRendererTypes.h:14: Error: 'Invalid_get' is multiply defined in the generated target language module in scope 'OsmAndCoreJNI'.
/[...]/MapTypes.h:30: Error: Previous declaration of 'Invalid_get'
/[...]/MapStyle.h:24: Error: 'Invalid_get' is multiply defined in the generated target language module in scope 'OsmAndCoreJNI'.
/[...]/MapTypes.h:30: Error: Previous declaration of 'Invalid_get'

I believe that this is wrong, since "Invalid" doesn't belong to global scope (since it's enum class, not enum). Taking into account that current HEAD is unstable 3.0.0, I wonder if enum classes are already supported, or they are just treated as regular enums.

Array with more than two dimensions

Array with more than two dimensions, e.g. extern double x[2][3][4]; lead to wrapped code with compile errors:

swig_wrap.c: In function ‘_wrap_x_set’:
swig_wrap.c:2425:50: error: incompatible types when assigning to type ‘double[4]’ from type ‘double’
           for (; jj < (size_t)3; ++jj) x[ii][jj] = inp[ii][jj];
                                                  ^

D swig : missing override on overridden methods (new requirement since D 2.063)

clang warning in SWIG_Python_ConvertPtrAndOwn

Hi,

I got a warning with swig 2.0.9 when compiling a python wrapper with clang 3.2:

In the embedded function SWIG_Python_ConvertPtrAndOwn:
res = SWIG_AddCast(res);

The compiler output:
/home/michel/projects/libftdi/build_py3/bindings/ftdi1PYTHON_wrap.c:2369:23: warning: explicitly assigning a variable of type 'int' to itself [-Wself-assign]
res = SWIG_AddCast(res);
~~~ ^ ~~~
2 warnings generated.

Regards,

greaterthan and lessthan syntax error in template

I am getting the error below when trying to wrap boost::units.

'''/usr/include/boost/units/quantity.hpp:50: Error: Syntax error in input(1).
error: command 'swig' failed with exit status 1'''

i think it is related to the > symbol in the line below. Is there any workaround to wrap this while it is being fixed in swig?

struct is_narrowing_conversion_impl : mpl::bool_< (sizeof(Source) > sizeof(Destination)) > {};

Lua wrappers for C++ code no longer compile under Visual Studio 2010

After updating from SWIG 2.0.12 to 3.0.0 Lua wrappers that are generated for C++ code no longer compile under Visual Studio 2010.

Steps to reproduce:

open Visual Studio Command Prompt (2010)
navigate to SWIG's Examples\lua\class directory
execute the following commands:

swig.exe -c++ -lua example.i
cl.exe /c example_wrap.cxx /I path\to\lua\include\directory

Expected results:

compilation succeeds

Actual results:

compilation fails with the following error:

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

example_wrap.cxx
example_wrap.cxx(1722) : error C3861: 'snprintf': identifier not found

The above description assumes that swigwin-3.0.0 (executable and source code) is used.

As far as I can tell, other versions of Visual Studio are affected by this issue as well: the snprintf function is still missing in VS 2013.

[Lua libs] Update to 2.0.11 causes void data to be returned at end of non-void functions

After updating swig to version 2.0.11, the functions
SWIGINTERN int SWIG_Lua_namespace_register(lua_State* L, swig_lua_namespace* ns)
and
SWIGINTERN int SWIG_Lua_add_namespace_details(lua_State* L, swig_lua_namespace* ns)
to return void when int was expected. This is fixed by the following patch:

diff --git a/Lib/lua/luarun.swg b/Lib/lua/luarun.swg
index 4d851bd..8485ed4 100644
--- a/Lib/lua/luarun.swg
+++ b/Lib/lua/luarun.swg
@@ -524,7 +524,7 @@ SWIGINTERN int SWIG_Lua_add_namespace_details(lua_State* L, swig_lua_namespace*

/* clear stack - remove metatble */

lua_pop(L,1);

return 0;
}

/* helper function. creates namespace table and add it to module table /
@@ -555,6 +555,7 @@ SWIGINTERN int SWIG_Lua_namespace_register(lua_State L, swig_lua_namespace* ns)

lua_setmetatable(L,-2); /* set metatable /
lua_rawset(L,-3); / add namespace to module table */

return 0;
}
/* -----------------------------------------------------------------------------
global variable support code: classes

r fails director_nspace_director_name_collision

r fails this regression test. The problem is that R should add the namespace to the internal methods.

Support %nspace for PHP

Hello,

It would be quite nice if Swig could manager PHP namespaces.
Il is quite similar to the java namespacing.

Thank you !

Typedef matching rules for 'char const' inconsistent

See the debugging output below, the lookup for 'char const [ANY]' is skipped, among others, in the case that a typedef as defined below is used. (in swig 2.0.9)

typedef char A_string[128 + 8];

Searching for a suitable 'default' typemap for: char const prefix[20+1]
Looking for: char const prefix[20+1]
Looking for: char const [20+1]
Looking for: char const prefix[ANY]
Looking for: char const [ANY]
Looking for: char prefix[20+1]
Looking for: char [20+1]
Looking for: char prefix[ANY]
Looking for: char [ANY]
Looking for: SWIGTYPE const prefix[ANY]
Looking for: SWIGTYPE const [ANY]
Looking for: SWIGTYPE prefix[ANY]
Looking for: SWIGTYPE [ANY]
Looking for: SWIGTYPE prefix[]
Looking for: SWIGTYPE []
Looking for: SWIGTYPE *prefix
Looking for: SWIGTYPE *
Looking for: SWIGTYPE prefix
Looking for: SWIGTYPE
None found

Searching for a suitable 'default' typemap for: A_string const device_name
Looking for: A_string const device_name
Looking for: A_string const
Looking for: A_string device_name
Looking for: A_string
Looking for: char const device_name[128+8]
Looking for: char const [128+8]
Looking for: char device_name[128+8]
Looking for: char [128+8]
Looking for: char device_name[ANY]
Looking for: char [ANY]
Looking for: SWIGTYPE const device_name[ANY]
Looking for: SWIGTYPE const [ANY]
Looking for: SWIGTYPE const device_name[]
Looking for: SWIGTYPE const []
Looking for: SWIGTYPE *const device_name
Looking for: SWIGTYPE *const
Looking for: SWIGTYPE const device_name
Looking for: SWIGTYPE const
Looking for: SWIGTYPE device_name
Looking for: SWIGTYPE
None found

Error when compiling with clang with -std=c++11 -stdlib=libc++

When trying to use c++11 mode with clang, i.e. the -std=c++11 -stdlib=libc++ flags are set, the swig generated cxx cannot be compiled.

An example of the error:

/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:11297:24: error: no matching member function for call to 'erase'
      result = (arg1)->erase(arg2);
               ~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    __attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
                                                                           ^
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: requires 2 arguments, but 1 was provided
    iterator erase(const_iterator __first, const_iterator __last);
             ^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:11376:24: error: no matching member function for call to 'erase'
      result = (arg1)->erase(arg2,arg3);
               ~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator erase(const_iterator __first, const_iterator __last);
             ^
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: requires single argument '__position', but 2 arguments were provided
    __attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
                                                                           ^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:11982:24: error: no matching member function for call to 'insert'
      result = (arg1)->insert(arg2,(std::vector< int >::value_type const &)*arg3);
               ~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, const_reference __x);
             ^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, value_type&& __x);
             ^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, initializer_list<value_type> __il)
             ^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
        insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
        insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: requires 3 arguments, but 2 were provided
    iterator insert(const_iterator __position, size_type __n, const_reference __x);
             ^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:12063:15: error: no matching member function for call to 'insert'
      (arg1)->insert(arg2,arg3,(std::vector< int >::value_type const &)*arg4);
      ~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, size_type __n, const_reference __x);
             ^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate template ignored: deduced conflicting types for parameter '_InputIterator' ('unsigned long' vs. 'int')
        insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate template ignored: deduced conflicting types for parameter '_ForwardIterator' ('unsigned long' vs. 'int')
        insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
    iterator insert(const_iterator __position, const_reference __x);
             ^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
    iterator insert(const_iterator __position, value_type&& __x);
             ^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
    iterator insert(const_iterator __position, initializer_list<value_type> __il)
             ^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:14674:24: error: no matching member function for call to 'erase'
      result = (arg1)->erase(arg2);
               ~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    __attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
                                                                           ^
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: requires 2 arguments, but 1 was provided
    iterator erase(const_iterator __first, const_iterator __last);
             ^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:14753:24: error: no matching member function for call to 'erase'
      result = (arg1)->erase(arg2,arg3);
               ~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator erase(const_iterator __first, const_iterator __last);
             ^
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: requires single argument '__position', but 2 arguments were provided
    __attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
                                                                           ^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:15359:24: error: no matching member function for call to 'insert'
      result = (arg1)->insert(arg2,(std::vector< double >::value_type const &)*arg3);
               ~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, const_reference __x);
             ^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, value_type&& __x);
             ^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, initializer_list<value_type> __il)
             ^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
        insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
        insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: requires 3 arguments, but 2 were provided
    iterator insert(const_iterator __position, size_type __n, const_reference __x);
             ^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:15440:15: error: no matching member function for call to 'insert'
      (arg1)->insert(arg2,arg3,(std::vector< double >::value_type const &)*arg4);
      ~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
    iterator insert(const_iterator __position, size_type __n, const_reference __x);
             ^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate template ignored: deduced conflicting types for parameter '_InputIterator' ('unsigned long' vs. 'double')
        insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate template ignored: deduced conflicting types for parameter '_ForwardIterator' ('unsigned long' vs. 'double')
        insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
        ^
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
    iterator insert(const_iterator __position, const_reference __x);
             ^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
    iterator insert(const_iterator __position, value_type&& __x);
             ^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
    iterator insert(const_iterator __position, initializer_list<value_type> __il)
             ^
8 errors generated.

Nested class director generates incorrect constructor "wrap:action"

Directors for nested classes create an incorrect wrapped constructor call "wrap:action". The call should look like new namespace_class_nestedclass() but instead is missing the containing class name and generates new namespace_nestedclass(). I can resolve this by modifying https://github.com/swig/swig/blob/master/Source/Swig/cwrap.c#L1253 and retrieving "sym:name" from n, the current node, instead of parent. I don't understand near enough about the code to know if this is a correct fix or a horrible hack, so I'm not bothering with a PR in hopes that someone who is familiar with the code can comment.

Java/CSharp sources input argument conversion

In java.cxx and csharp.cxx at multiple lines you make the conversion of input argument by your own one.

It will better to use "in" typemap to do so.

trying to swig openssh

I have just cloned swig on the master branch to be sure to have the latest version and I've built it from source. It says:

$ swig -version
SWIG Version 2.0.11

I am trying to create a (detailed) SWIG interface (for PHP) for libssl:

$ openssl version
OpenSSL 1.0.1c 10 May 2012

I am mostly interested in using the functions listed in:

include "/usr/include/openssl/ecdsa.h"

include "/usr/include/openssl/ec.h"

The problem is that I am getting syntax errors all over the place:

/usr/include/openssl/asn1.h:556: Error: Syntax error in input(1).

GCC seems to have no problem with this file, though:

$ gcc /usr/include/openssl/asn1.h -o asn1
$ ls asn1
asn1

The culprit seems to be the following macro use on line 556:

DECLARE_ASN1_ENCODE_FUNCTIONS_const(ASN1_SEQUENCE_ANY, ASN1_SEQUENCE_ANY)

Declared earlier on line 330:

define DECLARE_ASN1_ENCODE_FUNCTIONS_const(type, name) \

type *d2i_##name(type **a, const unsigned char **in, long len); \
int i2d_##name(const type *a, unsigned char **out); \
DECLARE_ASN1_ITEM(name)

Any idea how I can go about dealing with this issue?

D swig: idea for dealing with C++ multiple inheritance

Currently D swig generated wrappers will only emit methods from the 1st parent of a class, eg: class A: public B1,B2,B3{}; will result in :
class A: B1{} and only show methods inherited from B1 plus new methods from A.

How about the following:

class A : B1{
private void*ptr;
this(void*ptr){...}
//either call it as or opCast, except opCast will hinder other casting cases
T as(T) if(is(T:B1)|| is(T:B2) || is(T:B3) ) {
  return cast(T)ptr;
}
//optionally we can also add this:
 alias as!B2 this;
//and once/if multiple alias this supported:
alias as!B3 this;
}

That way, methods inherited from B1,B2,B3 get supported at no cost:

auto a=new A;
a.B1_method1; //already available since A:B1
a.as!B2.B_method1; //already available since A:B1
a.as!B3.B_method1; //already available since A:B1

Compile issues with Intel compiler

We use an Intel compiler that has the following issues with the Python and Lua generated code. These changes should work fine in all compilers.

 index 8803c66..2162f0f 100644
 --- a/Lib/lua/luarun.swg
 +++ b/Lib/lua/luarun.swg
 @@ -720,7 +720,7 @@ SWIGINTERN int SWIG_Lua_iterate_bases(lua_State *L, swig_type_info * S
      size_t bases_count;
      int result = SWIG_ERROR;
      int bases_table;
 -    (void)swig_type;
 +    swig_type = NULL;
      lua_getmetatable(L,first_arg);

      /* initialise base search */
 @@ -731,7 +731,7 @@ SWIGINTERN int SWIG_Lua_iterate_bases(lua_State *L, swig_type_info * S
      bases_table = lua_gettop(L);
  #else
      /* In elua .bases table doesn't exist. Use table from swig_lua_class */
 -    (void)bases_table;
 +    bases_table = NULL;
      assert(swig_type!=0);
      swig_module_info *module=SWIG_GetModule(L);
      swig_lua_class **bases= ((swig_lua_class*)(swig_type->clientdata))->bases;
 diff --git a/Lib/python/pyinit.swg b/Lib/python/pyinit.swg
 index b44c2c8..fcb025b 100644
 --- a/Lib/python/pyinit.swg
 +++ b/Lib/python/pyinit.swg
 @@ -377,11 +377,11 @@ SWIG_init(void) {
    PyObject *thisown_descr;
    int i;

 -  (void)builtin_pytype;
 -  (void)builtin_base_count;
 -  (void)builtin_basetype;
 -  (void)tuple;
 -  (void)static_getset;
 +  builtin_pytype = NULL;
 +  builtin_base_count = 0;
 +  builtin_basetype = NULL;
 +  tuple = NULL;
 +  static_getset = NULL;

    /* metatype is used to implement static member variables. */
    metatype_args = Py_BuildValue("(s(O){})", "SwigPyObjectType", &PyType_Type);
 diff --git a/Lib/python/pyrun.swg b/Lib/python/pyrun.swg
  #ifdef SWIGPYTHON_BUILTIN
 -  (void)obj;
 +  obj = NULL;
  # ifdef PyWeakref_CheckProxy
    if (PyWeakref_CheckProxy(pyobj)) {
      pyobj = PyWeakref_GET_OBJECT(pyobj);

error: invalid conversion from 'const jdouble* {aka const double}' to 'jdouble {aka double*}' [-fpermissive]

When compiling to Java, I sometimes get the error given in title. I must confess that I have no idea of why reducing the constness should be an error anyhow.

This happens on kfreebsd-i386, kfreebsd-amd64 and sparc:

https://buildd.debian.org/status/fetch.php?pkg=simgrid&arch=kfreebsd-amd64&ver=3.11.1-1&stamp=1402116289
https://buildd.debian.org/status/fetch.php?pkg=simgrid&arch=kfreebsd-i386&ver=3.11.1-1&stamp=1402117802
https://buildd.debian.org/status/fetch.php?pkg=simgrid&arch=sparc&ver=3.11.1-1&stamp=1402118699

But this does not occurs on the other Debian architectures. I'm completely puzzeled, and any help would be welcomed. I'll use -fpermisive for the time being, but I don't quite like it.

The code that is compiled is visible here:
http://sources.debian.net/src/simgrid/3.11.1-1/src/bindings/java

Thanks for that wonderful piece of code by the way. It saved my soul :)

ruby %alias on functions

It is not possible to apply %alias to native C functions. Code generation silently failes (with swigwin-2.0.6).

Example:
mod.i

  %module mod

  %{
  #include "mod.h"
  %}

  %alias foo "bar";
  %include "mod.h"

mod.h

  #define bar foo
  extern int foo(int i);

mod.c

  #include "mod.h"
  int foo(int i)
  {
     return i + 1;
  }

Lua __tostring() inheritance regression

@v-for-vandal

Generated Lua bindings used to correctly inherit __tostring() from a parent class, but no longer do.

I'll attach a patch against an existing testcase which demonstrates the issue - before these changes, tostring() returns Foo for both an object of class Foo and an object of class FooSub, but it no longer does.

Last two lines of output before these changes:

Foo
Foo

Output now:

Foo
<FooSub userdata: 0xddaa58>

git bisect shows the problem was introduced by this merge:

1be97ed Merge Lua changes - branch 'class_p1' of github.com:v-for-vandal/swig into v-for-vandal-class_p1

On that branch, this commit is the first where it fails, but many earlier ones aren't testable due to the segfault that was fixed here, so I doubt this is actually where the problem was introduced:

* ec629be (refs/bisect/bad) Fixing segfault

Passing -no-old-metatable-bindings to swig doesn't fix it - instead the testcase fails with:

/usr/bin/lua5.2: ./cpp_basic_runme.lua:45: attempt to index field 'global_fptr' (a nil value)
stack traceback:
    ./cpp_basic_runme.lua:45: in main chunk
    [C]: in ?

use of undeclared identifier 'DohClose'

I'm following the user guide to code a Matlab module for SWIG.

In the section "39.10.6 Module I/O and wrapper skeleton", the line "Close(f_begin);" causes the following error message:


Modules/matlab.cxx:268:5: error: use of undeclared identifier 'DohClose'
    Close(f_begin);
    ^
../Source/DOH/doh.h:427:28: note: expanded from macro 'Close'
#define Close              DohClose

flatnested feature for inner classes

In the code below for C#/Java, the Minner and RightInside classes disappear and are not generated at all.

%feature("flatnested") Minner;
%inline %{
class Ooter {
  class Minner {
    class RightInside {
    };
  };
};
%}

@wkalinin would you mind taking a look?

Default copy ctors for C/C++ structs (Java and perhaps other languages)

In c/c++, a default copy ctor is created for all structs/classes. In case of simple (POD?) types, it resolves into a one-line memcpy, which is fine as long as we dont have pointers etc. that needs deepcopy.

However on the Java side (which is what I work with right now), this default copy ctor is not automatically reflected (understantably). This forces me to wrap all my (many!) POD structs in a template class that explictly implements a copy ctor, to be able to have them in Java.

It would be cool in someway to be able to tell Swig to generate a simple default copy ctor without having to write the code manually in the .i file.

To achieve this, I was thinking using the std::is_pod defined in c++11, and skip it on older compilers. Would be glad to contribute.

Swig compilation error on Centos5.8

Dear all,

I'm quite a newbee in compiling applications. While trying to install swig 1.3.40 during "make" execution I ran into

g++ -DHAVE_CONFIG_H   -I../Source/Include -I../Source/CParse -I../Source/Include -I../Source/DOH -I../Source/CParse -I../Source/Preprocessor -I../Source/Swig -I../Source/Modules   -g -O2 -Wall -W -ansi -pedantic -MT Modules/allegrocl.o -MD -MP -MF $depbase.Tpo -c -o Modules/allegrocl.o Modules/allegrocl.cxx &&\
        mv -f $depbase.Tpo $depbase.Po
/tmp/ccG9S2WG.s: Assembler messages:
/tmp/ccG9S2WG.s:6369: Error: bad register name `%'
/tmp/ccG9S2WG.s:7280: Error: bad register name `%'
/tmp/ccG9S2WG.s:8259: Error: bad register name `%'
/tmp/ccG9S2WG.s:11930: Error: bad register name `%'
/tmp/ccG9S2WG.s:13747: Error: bad register name `%'
/tmp/ccG9S2WG.s:13751: Error: bad register name `%'
/tmp/ccG9S2WG.s:13884: Error: bad register name `%'
make[2]: *** [Modules/allegrocl.o] Error 1
make[2]: Leaving directory `/tmp/swig/swig-1.3.40/Source'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/swig/swig-1.3.40/Source'
make: *** [source] Error 2

Though I scanned all the usual source, I couldn't find a solution. I would be very glad if you can point me into the right direction.

Best

Dummy issue (should have used a pull request) #2

Common Lisp backend does not put package before &body (should be cl:&body)

This causes problems with eg

(cl:defmacro defanonenum (&body enums)
   "Converts anonymous enums to defconstants."
  `(cl:progn ,@(cl:loop for value in enums
                        for index = 0 then (cl:1+ index)
                        when (cl:listp value) do (cl:setf index (cl:second value)
                                                          value (cl:first value))
                        collect `(cl:defconstant ,value ,index))))

when the current package does not use :common-lisp. Some other =lambda-list-keywords= are already qualified with cl:, but all of them should be.

PS.: Sorry for not using the sf.net bug tracker, I gave up after three 500 errors.

Go Wrapping should not prepend a Get to a variable getter.

From their style guide: http://golang.org/doc/effective_go.html#Getters

Go doesn't provide automatic support for getters and setters. There's nothing wrong with providing getters and setters yourself, and it's often appropriate to do so, but it's neither idiomatic nor necessary to put Get into the getter's name. If you have a field called owner (lower case, unexported), the getter method should be called Owner (upper case, exported), not GetOwner. The use of upper-case names for export provides the hook to discriminate the field from the method. A setter function, if needed, will ikely be called SetOwner. Both names read well in practice:

typename wrong scoping

There is an issue with swig and program using complete typename and typedef

for example
class B {
typedef int TYPE2;
};

Class A {
typedef B TYPE1;
};

class c {
typename A::TYPE1::TYPE2 a;
};

during the SwigType_typedef_resolve_all the typename "A::TYPE1::TYPE2"
will be splitted like this
prefix: A::B
basename: TYPE2
It will fail to find the scope associated to A::B and will resolve "A::TYPE1::TYPE2" as "A::TYPE1::TYPE2" and not int

Python warnings from swig-generated code with latest clang on Mac

With swig @2.0.10 (devel) and the latest clang from XCode 5 on Mac the swig-generated code in scipy generates tons of warnings:
scipy/scipy#2944

Can you have a look if it's possible to adapt swig to generate code that results in fewer warnings?

Go: SWIG doesn't work on Windows

Hey guys, sorry for the mistake when submitting.

I'm trying to build Go bindings for C++ lib, and while it does work on Linux, Mac, here are the steps I have to do to modify the cxx file to make it work on Windows, based in part on https://groups.google.com/forum/#!topic/golang-nuts/9L0U4Q7AtyE

First of all, change all struct swigargs to be __attribute__((__packed__)), according to https://code.google.com/p/go/source/browse/src/cmd/cgo/out.go#530 :

$ sed -i '' 's/} \*swig_a/} __attribute__((__packed__)) \*swig_a/g' file_wrap.cxx

For instance

  struct swigargs {
    long : 0;
    intgo result;
  } __attribute__((__packed__)) *swig_a = (struct swigargs *) swig_v;

However, on Win32, long long int is broken, suggested fix is, according to https://code.google.com/p/go/issues/detail?id=6541 :

$ sed -i '' 's/__attribute__((__packed__))/__attribute__((__packed__, __gcc_struct__))/g' file_wrap.cxx

  struct swigargs {
    long : 0;
    intgo result;
  } __attribute__((__packed__, __gcc_struct__)) *swig_a = (struct swigargs *) swig_v;

Also, Windows doesn't resolve symbols at compile time, so we need to properly set these symbols in a DllMain, and then have the file use them, see the dllmain file here: https://gist.github.com/steeve/7152742/raw/dllmain.cxx

Finally, we need to fix the imports, I do it like so:

# Comment out externs
    sed -i '' 's/\(extern void\)/\/\/\1/' $@
# Insert dllmain
    cat dllmain.i $@ > [email protected]
    mv [email protected] $@
# Fix imports by specifying then to the external dll, and commenting the x_wrap_* symbols
    sed -i '' 's/\(#pragma dynimport _ _\)/\/\/\1/' libtorrent_gc.c
    sed -i '' 's/\(#pragma dynimport.*\)\(""\)/\1"$(LIBRARY_NAME)"/g' libtorrent_gc.c
    sed -i '' 's/\(static void (\*x_wrap_\)/\/\/\1/g' libtorrent_gc.c
    sed -i '' 's/cgocall(x\(_wrap_.*\)/cgocall(\1/g' libtorrent_gc.c

And here is a snippet of my Makefile to do that:

$(SRCS) $(GOFILES): $(SWIG_FILES)
    $(SWIG) $(SWIG_FLAGS) -o $@ -outdir . $<
# It should always be like this, according to https://code.google.com/p/go/source/browse/src/cmd/cgo/out.go
    sed -i '' 's/} \*swig_a/} __attribute__((__packed__)) \*swig_a/g' $@
# Temp fix for https://code.google.com/p/go/issues/detail?id=6541
# See also https://code.google.com/p/go/issues/detail?id=5603
ifeq ($(CC), gcc)
    ifneq (,$(filter $(ARCH),x86 x64))
        sed -i '' 's/__attribute__((__packed__))/__attribute__((__packed__, __gcc_struct__))/g' $@
    endif
endif
ifeq ($(OS), Windows_NT)
# Patch SWIG generated files for succesful compilation on Windows.
# Based on https://groups.google.com/forum/#!topic/golang-nuts/9L0U4Q7AtyE
# Comment out externs
    sed -i '' 's/\(extern void\)/\/\/\1/' $@
# Insert dllmain
    cat dllmain.i $@ > [email protected]
    mv [email protected] $@
# Fix imports by specifying then to the external dll, and commenting the x_wrap_* symbols
    sed -i '' 's/\(#pragma dynimport _ _\)/\/\/\1/' libtorrent_gc.c
    sed -i '' 's/\(#pragma dynimport.*\)\(""\)/\1"$(LIBRARY_NAME)"/g' libtorrent_gc.c
    sed -i '' 's/\(static void (\*x_wrap_\)/\/\/\1/g' libtorrent_gc.c
    sed -i '' 's/cgocall(x\(_wrap_.*\)/cgocall(\1/g' libtorrent_gc.c
endif

std::vector< boost::shared_ptr< X > > in python: iteration and indexing produce different results

Hi,

I am finding that when I put an empty (ie, pointing to NULL) boost::shared_ptr into a std::vector, and then look at it in Python, the iteration and indexing results are different. That is,

X = myswigged.getListOfStuff()
for i,x in enumerate(X):
    print '  iteration:', x
    print '  indexing:', X[i]

produce different results; indexing notices that the empty (null) boost::shared_ptr is null and returns None; the iteration does not, producing a seemingly-valid boost::shared_ptr that will explode upon use.

Minimal test case: http://broiler.astrometry.net/~dstn/temp/test.tgz

wget http://broiler.astrometry.net/~dstn/temp/test.tgz
tar xzf test.tgz
python setup.py build_ext --inplace
python runtest.py

I have verified that this occurs in swig 2.0.10 and git master.

thanks,
dustin

D swig: public keyword is redundant for class methods

D swig generated wrappers shows 'public' for methods.
That's redundant for D, where public is by default.

Python: swig_import_helper problems in frozen application.

SWIG autogenerates a swig_import_helper() Python function, which from what I can see, attempts to do relative imports in a way that remains valid syntax in Python 2.4. Unfortunately, the use of __file__ doesn't work in frozen applications, and it falls back to import %s (line), which doesn't work as a relative import in Python 3.

If I change the line to from . import %s, it works again. I guess that is invalid syntax on Python 2.4, but I don't have such an old version of Python handy to test. Projects that work on Python 3 rarely support Python 2.4, so it may be practical to make this an option.

This was reported as a bug with cx_Freeze, a Python freezing tool, but I don't see a good way to fix it in cx_Freeze, so I wanted to bring it up here.

Lib/ruby/rubycomplex.swg: %swig_fromcplx_conv supports Ruby >= 1.9 only

Reference: http://sourceforge.net/mailarchive/message.php?msg_id=30914596

%swig_fromcplx_conv calls rb_complex_new() which is available from Ruby 1.9 on only

generation failed with "Syntax error in input(2)" for valid header file..

i tried to generate swig for exisiing header files. The process fail with the mesage:
ericdef_gui.h(200): error : Syntax error in input(2).

The corresponding header code:

typedef int (STDCALL *T_GUI_EricMessageDialog) (
    const char *text,
    const char *caption,
    int type
);

Help needed :-)
Thanks in advance
Oliver

typedef issue between member function and static member function

I wrote a .i file and generated C# wrapper on swig 3.0.0

typedef unsigned int utf32;
%typemap(ctype) const utf32* "utf32*"
%typemap(ctype) utf32* "utf32*"

class TestClass
{
public:
    void Test( const utf32* v);
    static void TestStatic( const utf32* v);
};

The wrapper is generated as follows.

SWIGEXPORT void SWIGSTDCALL CSharp_TestClass_Test(void * jarg1, utf32* jarg2) {
  TestClass *arg1 = (TestClass *) 0 ;
  utf32 *arg2 = (utf32 *) 0 ;

  arg1 = (TestClass *)jarg1; 
  arg2 = (utf32 *)jarg2; 
  (arg1)->Test((utf32 const *)arg2);
}

SWIGEXPORT void SWIGSTDCALL CSharp_TestClass_TestStatic(utf32* jarg1) {
  utf32 *arg1 = (utf32 *) 0 ;

  arg1 = (utf32 *)jarg1; 
  TestClass::TestStatic((unsigned int const *)arg1);
}

In the member function, arg2 is cast to utf32 const_.
On the other hand, in the static member function, arg1 is cast to unsigned int cont_.
Normally, it is no problem. But I think that it is a bug.

PHP 5.5: c++ class not converting properly

Hey. I have just used swig to generate a wrapper for a c++ class. Unfortunately, I get this while compiling:

/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:14: error: ‘zend_module_entry’ does not name a type
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:27: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:28: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:29: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:30: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:31: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:33: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:34: error: expected constructor, destructor, or type conversion before ‘(’ token
make: *** [easywsclient.lo] Error 1

File in question is: https://gist.github.com/IngwiePhoenix/6898536
My config.m4 file is: https://gist.github.com/IngwiePhoenix/6898541

Any suggestions here? o.o

C++ Direct initialization is not supported/parsed correctly

The following line, c++ direct initialization of a integer, leads to a parse error:

int a(3);

480: Error: Syntax error in input(1).

Furthermore, constants defined using direct initialization are not wrapped as constants:

const int b(static_cast<int>(ENUM_ITEM));

is translated as function with an argument.

Dummy issue (should have used a pull request)

Lua is missing some typecheck typemaps

The type-checking code SWIG generates in overload-resolution wrapper functions incorrectly ignores INPUT typemaps (although these typemaps are correctly used inside the per-overload wrapper function that does the actual argument conversion and calling).

This means that when one tries to call the overloaded function from the target language with some value which the INPUT typemap should convert, the overload-resolution wrapper thinks it's the wrong type, and in most cases that means overload resolution will fail and it will signal a type error.

I noticed this problem with the Lua backend, although I don't know if it's specific to that backend or a more general issue.

Here's a test case that illustrates the problem (instructions for compiling etc are in the comments):
https://gist.github.com/snogglethorpe/7521146

[I'm not actually sure how SWIG would do this correctly though, as typemaps don't seem to have a way of specifying code to just check the type...]

std::multimap error

In Swig 2.0.4, wrapping a std::multimap fails with an error.

Copying the SWIG_Traits_frag(std::pair<>) from std/std_map.i into std/std_multimap.i eliminated the error messages.

SWIG and Qt

Due to some Qt-specific things like "Signal/Slot, QObject parenting ownership, Qt Properties, QVariant, and custom classes for string, vectors, etc.", it's current not possible to generate full Qt bindings using SWIG.

Creating a github issue for the ideas recently discussed in here and here in the hopes of broader awareness and call for help.

Thread Safety Bugfix

There is a severe bug regarding thread savity in the functions
SWIG_TypeCheckStruct and SWIG_TypeCheck, that did cost me quite some time to figure out. I propose to generally apply the following bugfix, so others do not run into this too.

The commented code below in these functions is not thread safe, as the swig_type_info structures are static. So using for example multiple Lua States, running on different threads results in hard to find and reproduce, mind blowing, random errors and all kinds of strange misbehaviour...

The function is at least used commonly in the generated wrapper functions for Lua.
And I guess it is also used for all the other languages as well, but I have not checked this. So I guess without this bugfix, probalbly all language wrappers are NOT thread safe without the following fix:

/*
  Check the typename
*/
SWIGRUNTIME swig_cast_info *
SWIG_TypeCheck(const char *c, swig_type_info *ty) {
  if (ty) {
    swig_cast_info *iter = ty->cast;
    while (iter) {
      if (strcmp(iter->type->name, c) == 0) {
        if (iter == ty->cast)
          return iter;

        /*
        THREAD SAVITY BUGFIX. See also SWIG_TypeCheckStruct

        Move iter to the top of the linked list
        iter->prev->next = iter->next;
        if (iter->next)
          iter->next->prev = iter->prev;
        iter->next = ty->cast;
        iter->prev = 0;
        if (ty->cast) ty->cast->prev = iter;
        ty->cast = iter;
        */
        return iter;
      }
      iter = iter->next;
    }
  }
  return 0;
}

/*
  Identical to SWIG_TypeCheck, except strcmp is replaced with a pointer comparison
*/
SWIGRUNTIME swig_cast_info *
SWIG_TypeCheckStruct(swig_type_info *from, swig_type_info *ty) {

  if (ty) {
    swig_cast_info *iter = ty->cast;
    while (iter) {
      if (iter->type == from) {
        if (iter == ty->cast)
          return iter;

        /*                                                         
        THREAD SAVITY BUGFIX. 

        Move iter to the top of the linked list
        iter->prev->next = iter->next;
        if (iter->next)
          iter->next->prev = iter->prev;
        iter->next = ty->cast;
        iter->prev = 0;
        if (ty->cast) ty->cast->prev = iter;
        ty->cast = iter;
        */

        return iter;
      }
      iter = iter->next;
    }
  }
  return 0;
}

Alternate solutions:

Create a copy of the swig_type_info data structures on each thread,
possibly using the 'thread_local' specifier

SWIG misparses a method name in parentheses

SWIG misparses a method name in parentheses, which is sometimes used to avoid macro expansion (if there was a foo macro taking one argument in this case):

%module misparse
%inline %{
struct Foo {
    int (foo)(int i);
};
%}

With current trunk:

$ ./preinst-swig -c++ -python misparse.i 
misparse.i:3: Warning 504: Function Foo::int(foo) must have a return type. Ignored.

I believe this is valid C++ - GCC and clang are both happy with it.

I've not dug into the parser to try to work out what's happening.

Lua: Multiple GCC warnings and errors in luarun.swg using SWIG 3.0.0

Dear SWIG community:

I use GCC 4.8 with SWIG 3.0.0 and Lua.

The compiler g++ is run with -Wall -Werror .

When compiling the generated wrapper code, the compiler complains on several issues:

unused variable 'begin' [-Wunused-variable] -> This appears multiple times in the line
```
    int begin = lua_gettop(L);
```
I found a workaround adding
```
    if (begin==0){;}
```
to the same line to luaswig.swg using 'sed'. One can not replace the line by
```
    lua_gettop(L);
```
since in some C++ functions, the variable begin is indeed used.
Unused parameter 'swig_type' in luaswig.swg, line:
```
    SWIGINTERN int SWIG_Lua_iterate_bases(lua_State L, swig_type_info * swig_type, int first_arg, swig_lua_base_iterator_func func, int const ret)
```
Here I tried to resolve the problem by commenting out swig_type, but at another point in my project I enhance the SWIG-Lua bindings using
```
    #include "luarun.swg"
```
in a C++ source file. If I remove swig_type from the parameter list, the compiler complains that it needs the parameter at that point.

warning: unused parameter 'first_arg' [-Wunused-parameter]
in

SWIGINTERN int  SWIG_Lua_class_do_get(lua_State *L, swig_type_info *type, int first_arg, int *ret)

In the wrapper code, I have multiple compiler warnings
```
    XYZ defined, but not used (-Werror=unused-variable)
```
XYZ are entries like swig_string_constants and swig_string_Sf_SwigStatic_meta (with a class string being wrapped), swig_SwigModule_meta

There is even a compile error of a wrong cast. Here you need to replace

(unsigned long)lua_touserdata(L,1)

reinterpret_cast<size_t>(lua_touserdata(L,1))

To ensure quality control, I can not switch off -Wall -Werror in my project. Until SWIG 2.0.11 I was able to use a sequence of sed commands to find work arounds. But in this case, I would be very grateful if some of the SWIG developers could fix this issue.

Best regards
Sebastian

ccache-swig man file can not be build on OS X

yodl2man version 2 and 3 do not seem to support the '-o' flag (at least on OS X).

Instead yodl2man creates a file called ccache.man. Therefore make install will fail, because the created man file can not be found.

I created a patch that fixes this issue under OS X (attached below).

I did not issue a pull request, because the lines of Code seem to be with Swig since 2008 and I am not sure if the bug was never detected because the Makefile.in is only part of the development version or because I am running this code on OS X.

diff -u a/CCache/Makefile.in b/CCache/Makefile.in
--- a/CCache/Makefile.in    2014-01-18 06:35:52.000000000 +0100
+++ b/CCache/Makefile.in    2014-01-18 06:43:42.000000000 +0100
@@ -28,27 +28,27 @@
 all: $(PACKAGE_NAME)$(EXEEXT)

 # Note that HTML documentation is actually generated and used from the main SWIG documentation Makefile
-docs: $(PACKAGE_NAME).1 web/ccache-man.html
+docs: ccache.man web/ccache-man.html

 $(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
    $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)

-$(PACKAGE_NAME).1: ccache.yo
-   -yodl2man -o $(PACKAGE_NAME).1 ccache.yo
+ccache.man: ccache.yo
+   yodl2man -o ccache.man ccache.yo

 web/ccache-man.html: ccache.yo
    yodl2html -o web/ccache-man.html ccache.yo

-install: $(PACKAGE_NAME)$(EXEEXT) $(PACKAGE_NAME).1
+install: $(PACKAGE_NAME)$(EXEEXT) ccache.man
    @echo "Installing $(PACKAGE_NAME)"
    @echo "Installing $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)"
    ${INSTALLCMD} -d $(DESTDIR)${bindir}
    ${INSTALLCMD} -m 755 $(PACKAGE_NAME)$(EXEEXT) $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
    @echo "Installing $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1"
    ${INSTALLCMD} -d $(DESTDIR)${mandir}/man1
-   ${INSTALLCMD} -m 644 ${srcdir}/$(PACKAGE_NAME).1 $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
+   ${INSTALLCMD} -m 644 ${srcdir}/ccache.man $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1

-uninstall: $(PACKAGE_NAME)$(EXEEXT) $(PACKAGE_NAME).1
+uninstall: $(PACKAGE_NAME)$(EXEEXT) ccache.man
    rm -f $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
    rm -f $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1

@@ -67,7 +67,7 @@
    /bin/rm -rf autom4te.cache

 maintainer-clean: distclean
-   /bin/rm -f $(PACKAGE_NAME).1 web/ccache-man.html
+   /bin/rm -f ccache.man web/ccache-man.html


 # FIXME: To fix this, test.sh needs to be able to take ccache from the