@@ -27,7 +27,7 @@ Version 4.0.2 (8 Jun 2020)
2727 [D] #1593 Replace broken imports when using newer versions of D.
2828
29292020-05-29: ZackerySpytz
30- [Python] #1716 Performance improvements converting strings when using Python >= 3.3.
30+ [Python] #1716 Performance improvements when converting strings when using Python >= 3.3.
3131
32322020-05-28: ZackerySpytz
3333 #1776 Quite dramatically decrease run times when generating very large interface files by changing
@@ -74,8 +74,8 @@ Version 4.0.2 (8 Jun 2020)
7474 [Ruby] #1651 Add std::auto_ptr<> typemaps.
7575
76762020-01-31: ZackerySpytz
77- [Python] #1700 More robust error checking for failures in calls to Python C API:
78- PyBytes_AsStringAndSize () and PyString_AsStringAndSize() .
77+ [Python] #1700 The Python C API functions PyBytes_AsStringAndSize() and
78+ PyString_AsStringAndSize () are now checked for failure .
7979
80802020-01-31: vadz
8181 [Python] #1710 Fix crash parsing empty docstrings.
@@ -115,7 +115,7 @@ Version 4.0.2 (8 Jun 2020)
115115
1161162020-01-13: wsfulton
117117 [Python] #1595 Python -builtin constructors silently ignored keyword arguments.
118- Instead of silenty ignoring them, now a "TypeError: f() takes no keyword arguments"
118+ Instead of silently ignoring them, now a "TypeError: f() takes no keyword arguments"
119119 exception is thrown if keyword arguments are used. Hence constructors and normal methods/
120120 functions behave in the same way. Note, -keyword should be used with -builtin to obtain
121121 keyword argument support.
@@ -200,7 +200,7 @@ Version 4.0.1 (21 Aug 2019)
200200 VectorOverload(std::vector< Number,std::allocator< Number > >)
201201 VectorOverload(std::vector< int,std::allocator< int > >)
202202
203- The problem was due to some error handling that was not cleared during typehecking .
203+ The problem was due to some error handling that was not cleared during typechecking .
204204 In this case an error was not cleared when the elements in the list failed the
205205 typecheck for converting to X. Only occurs in Python 3+.
206206
@@ -289,6 +289,7 @@ Version 4.0.1 (21 Aug 2019)
2892892019-05-22: ferdynator
290290 [PHP] #1528 Don't add a closing '?>' PHP tag to generated files.
291291 PSR-2 says it MUST be omitted for files containing only PHP.
292+
292293Version 4.0.0 (27 Apr 2019)
293294===========================
294295
@@ -3137,7 +3138,7 @@ Version 3.0.3 (30 Dec 2014)
31373138
313831392014-09-12: olly
31393140 [PHP] Add support for specifying any PHP interfaces a wrapped class
3140- implements, e.g.: %typemap("phpinterfaces") MyIterator "Iterator";
3141+ implements, e.g.: %typemap("phpinterfaces") MyIterator "Iterator"
31413142
314231432014-09-11: olly
31433144 [PHP] Fix throwing a PHP exception through C++ from a subclassed
@@ -3302,7 +3303,7 @@ Version 3.0.0 (16 Mar 2014)
33023303 project has been further extended. The C++11 support is comprehensive, but by no means complete
33033304 or without limitations. Full details for each new feature in C++11 is covered in the
33043305 CPlusPlus11.html chapter in the documentation which is included in SWIG and also available
3305- online at http ://www.swig.org/Doc3.0/CPlusPlus11.html.
3306+ online at https ://www.swig.org/Doc3.0/CPlusPlus11.html.
33063307
330733082014-03-14: v-for-vandal
33083309 [Lua] Numerous Lua improvements:
@@ -5784,7 +5785,7 @@ Version 2.0.0 (2 June 2010)
57845785
578557862010-02-27: wsfulton
57865787 License code changes: SWIG Source is GPL-v3 and library code license is now clearer
5787- and is provided under a very permissive license. See http ://www.swig.org/legal.html.
5788+ and is provided under a very permissive license. See https ://www.swig.org/legal.html.
57885789
578957902010-02-13: wsfulton
57905791 [Ruby] A few fixes for compiling under ruby-1.9.x including patch from 'Nibble'.
@@ -8396,8 +8397,8 @@ Version 1.3.30 (November 13, 2006)
83968397 javabase/csbase typemap, eg in the following, 'Me' will be the base class,
83978398 no matter what Foo is really derived from in the C++ layer.
83988399
8399- %typemap(javabase, replace="1") Foo "Me";
8400- %typemap(csbase, replace="1") Foo "Me";
8400+ %typemap(javabase, replace="1") Foo "Me"
8401+ %typemap(csbase, replace="1") Foo "Me"
84018402
84028403 Previously it was not possible for the javabase/csbase typemaps to override the C++ base.
84038404
@@ -9884,7 +9885,7 @@ Version 1.3.28 (February 12, 2006)
98849885 solutions is to write:
98859886
98869887 %typemap(in) A * {...}
9887- %typemap(freeag) A * "";
9888+ %typemap(freeag) A * ""
98889889
98899890 overload 'freearg' with an empty definition.
98909891
@@ -11314,20 +11315,20 @@ Version 1.3.27 (October 15, 2005)
1131411315 then the typemap will be inserted without the block
1131511316 imposed by the brackets, similar to
1131611317
11317- %typemap(in) Hello "...";
11318+ %typemap(in) Hello "..."
1131811319
1131911320 So, why you don't just use the quote style?, because:
1132011321
1132111322 1.- The quote style doesn't get preprocessed, for example
1132211323
11323- %typemap(in) Hello "$1= SWIG_macro($1);";
11324+ %typemap(in) Hello "$1= SWIG_macro($1);"
1132411325
1132511326 here, SWIG_macro doesn't get expanded
1132611327
1132711328 2.- Inside a quote typemap, you have to use
1132811329 quotes carefully
1132911330
11330- %typemap(in) Hello "$1 = \"hello\" ";
11331+ %typemap(in) Hello "$1 = \"hello\" "
1133111332
1133211333 3.- You can't make emacs and/or other editors
1133311334 to indent inside a string!.
@@ -11529,7 +11530,7 @@ Version 1.3.26 (October 9, 2005)
1152911530
1153011531 %define hello(name, Type)
1153111532 %define name ## a(Type)
11532- %typemap(in) Type "hello;";
11533+ %typemap(in) Type "hello;"
1153311534 %enddef
1153411535 %enddef
1153511536
@@ -13525,7 +13526,7 @@ Version 1.3.23 (November 11, 2004)
1352513526 whereupon the default of 0 was used. You can get the same behaviour for C
1352613527 code by using the "default" typemap:
1352713528
13528- %typemap(default) int val "$1 = 0;";
13529+ %typemap(default) int val "$1 = 0;"
1352913530 %{
1353013531 void foo(int val);
1353113532 %}
@@ -13854,9 +13855,11 @@ Version 1.3.22 (September 4, 2004)
1385413855 specifiers from the C type. This makes it possible, for instance, to control
1385513856 whether a C "char" argument takes a Lisp character or a Lisp integer value.
1385613857 The default (taking Lisp characters) is done by these built-in typemaps:
13857- %typemap(ffitype) char ":char"; %typemap(lisptype) char "character";
13858+ %typemap(ffitype) char ":char"
13859+ %typemap(lisptype) char "character"
1385813860 If char means an integer instead, use these typemaps:
13859- %typemap(ffitype) char ":char"; %typemap(lisptype) char "integer";
13861+ %typemap(ffitype) char ":char"
13862+ %typemap(lisptype) char "integer"
1386013863
138611386408/22/2004: wsfulton
1386213865 As discussed in bug #772453, the SWIG library directory is now installed
@@ -18874,9 +18877,9 @@ Version 1.3.14 (August 12, 2002)
1887418877 shadowinterface
1887518878
1887618879 Note that it is possible to target a particular proxy class:
18877- %typemap(javaimports) Foo "import java.util.*";
18880+ %typemap(javaimports) Foo "import java.util.*"
1887818881 or a particular type wrapper class:
18879- %typemap(javaimports) double* "import java.math.*";
18882+ %typemap(javaimports) double* "import java.math.*"
1888018883 Note that $javaclassname in these typemaps are substituted with either the proxy
1888118884 classname when using proxy classes or the SWIGTYPE class name.
1888218885
@@ -19614,8 +19617,8 @@ Version 1.3.12 (June 2, 2002)
1961419617 typemap must exactly match up with the "in" or "ignore"
1961519618 typemap. For example:
1961619619
19617- %typemap(in) (char *data, int len) { ... };
19618- %typemap(freearg) char *data { ... };
19620+ %typemap(in) (char *data, int len) { ... }
19621+ %typemap(freearg) char *data { ... }
1961919622
1962019623 void foo(char *data, int len);
1962119624
@@ -21071,15 +21074,15 @@ Version 1.3.11 (January 31, 2002)
2107121074
2107221075 Second, a typemap can force a no-match by defining
2107321076
21074- %typemap(in) sometype "pass";
21077+ %typemap(in) sometype "pass"
2107521078
2107621079 If this is used, the typemap system will *not* record a
2107721080 typemap match for "sometype". This can be used to block
2107821081 selected typemaps. For example, if you wanted to disable
2107921082 a typemap feature for some type, you could do this.
2108021083
2108121084 // Do not allow global variables of type 'const char *' to be set.
21082- %typemap(varin) const char * "pass";
21085+ %typemap(varin) const char * "pass"
2108321086
2108421087 It might also be possible to use this to do subtle and
2108521088 strange things with typemaps. For example, if you wanted to
@@ -21093,8 +21096,8 @@ Version 1.3.11 (January 31, 2002)
2109321096 ... return a value ...
2109421097 }
2109521098 /* Block unqualified typemaps defined above */
21096- %typemap(ignore) const blah * "pass";
21097- %typemap(argout) const blah * "pass";
21099+ %typemap(ignore) const blah * "pass"
21100+ %typemap(argout) const blah * "pass"
2109821101 %typemap(in) const blah * {
2109921102 ... get input value ...
2110021103 }
@@ -21871,7 +21874,7 @@ Version 1.3.10 (December 10, 2001)
2187121874 %typemap directive can now accept nearly arbitrary keyword parameters.
2187221875 For example:
2187321876
21874- %typemap(in,parse="i",doc="integer") int "...";
21877+ %typemap(in,parse="i",doc="integer") int "..."
2187521878
2187621879 The purpose of the keyword parameters is to supply code generation
2187721880 hints to the target language module. The intepretation of the
@@ -23949,7 +23952,7 @@ Version 1.3 Alpha 4 (September 4, 2000)
2394923952 Typemaps can now be specified using string literals like
2395023953 this:
2395123954
23952- %typemap(in) int "$target = SvIV($source);";
23955+ %typemap(in) int "$target = SvIV($source);"
2395323956
2395423957 When code is specified like this, it is *NOT* enclosed
2395523958 inside a local scope (as with older typemap declarations).
0 commit comments