Cosmetic stray semi-colon removal after %typemap using quotes

This commit is contained in:
William S Fulton 2022-08-20 22:14:58 +01:00
commit c10a84c775
59 changed files with 258 additions and 256 deletions

40
CHANGES
View file

@ -3137,7 +3137,7 @@ Version 3.0.3 (30 Dec 2014)
2014-09-12: olly
[PHP] Add support for specifying any PHP interfaces a wrapped class
implements, e.g.: %typemap("phpinterfaces") MyIterator "Iterator";
implements, e.g.: %typemap("phpinterfaces") MyIterator "Iterator"
2014-09-11: olly
[PHP] Fix throwing a PHP exception through C++ from a subclassed
@ -8396,8 +8396,8 @@ Version 1.3.30 (November 13, 2006)
javabase/csbase typemap, eg in the following, 'Me' will be the base class,
no matter what Foo is really derived from in the C++ layer.
%typemap(javabase, replace="1") Foo "Me";
%typemap(csbase, replace="1") Foo "Me";
%typemap(javabase, replace="1") Foo "Me"
%typemap(csbase, replace="1") Foo "Me"
Previously it was not possible for the javabase/csbase typemaps to override the C++ base.
@ -9884,7 +9884,7 @@ Version 1.3.28 (February 12, 2006)
solutions is to write:
%typemap(in) A * {...}
%typemap(freeag) A * "";
%typemap(freeag) A * ""
overload 'freearg' with an empty definition.
@ -11314,20 +11314,20 @@ Version 1.3.27 (October 15, 2005)
then the typemap will be inserted without the block
imposed by the brackets, similar to
%typemap(in) Hello "...";
%typemap(in) Hello "..."
So, why you don't just use the quote style?, because:
1.- The quote style doesn't get preprocessed, for example
%typemap(in) Hello "$1= SWIG_macro($1);";
%typemap(in) Hello "$1= SWIG_macro($1);"
here, SWIG_macro doesn't get expanded
2.- Inside a quote typemap, you have to use
quotes carefully
%typemap(in) Hello "$1 = \"hello\" ";
%typemap(in) Hello "$1 = \"hello\" "
3.- You can't make emacs and/or other editors
to indent inside a string!.
@ -11529,7 +11529,7 @@ Version 1.3.26 (October 9, 2005)
%define hello(name, Type)
%define name ## a(Type)
%typemap(in) Type "hello;";
%typemap(in) Type "hello;"
%enddef
%enddef
@ -13525,7 +13525,7 @@ Version 1.3.23 (November 11, 2004)
whereupon the default of 0 was used. You can get the same behaviour for C
code by using the "default" typemap:
%typemap(default) int val "$1 = 0;";
%typemap(default) int val "$1 = 0;"
%{
void foo(int val);
%}
@ -13854,9 +13854,11 @@ Version 1.3.22 (September 4, 2004)
specifiers from the C type. This makes it possible, for instance, to control
whether a C "char" argument takes a Lisp character or a Lisp integer value.
The default (taking Lisp characters) is done by these built-in typemaps:
%typemap(ffitype) char ":char"; %typemap(lisptype) char "character";
%typemap(ffitype) char ":char"
%typemap(lisptype) char "character"
If char means an integer instead, use these typemaps:
%typemap(ffitype) char ":char"; %typemap(lisptype) char "integer";
%typemap(ffitype) char ":char"
%typemap(lisptype) char "integer"
08/22/2004: wsfulton
As discussed in bug #772453, the SWIG library directory is now installed
@ -18874,9 +18876,9 @@ Version 1.3.14 (August 12, 2002)
shadowinterface
Note that it is possible to target a particular proxy class:
%typemap(javaimports) Foo "import java.util.*";
%typemap(javaimports) Foo "import java.util.*"
or a particular type wrapper class:
%typemap(javaimports) double* "import java.math.*";
%typemap(javaimports) double* "import java.math.*"
Note that $javaclassname in these typemaps are substituted with either the proxy
classname when using proxy classes or the SWIGTYPE class name.
@ -21071,7 +21073,7 @@ Version 1.3.11 (January 31, 2002)
Second, a typemap can force a no-match by defining
%typemap(in) sometype "pass";
%typemap(in) sometype "pass"
If this is used, the typemap system will *not* record a
typemap match for "sometype". This can be used to block
@ -21079,7 +21081,7 @@ Version 1.3.11 (January 31, 2002)
a typemap feature for some type, you could do this.
// Do not allow global variables of type 'const char *' to be set.
%typemap(varin) const char * "pass";
%typemap(varin) const char * "pass"
It might also be possible to use this to do subtle and
strange things with typemaps. For example, if you wanted to
@ -21093,8 +21095,8 @@ Version 1.3.11 (January 31, 2002)
... return a value ...
}
/* Block unqualified typemaps defined above */
%typemap(ignore) const blah * "pass";
%typemap(argout) const blah * "pass";
%typemap(ignore) const blah * "pass"
%typemap(argout) const blah * "pass"
%typemap(in) const blah * {
... get input value ...
}
@ -21871,7 +21873,7 @@ Version 1.3.10 (December 10, 2001)
%typemap directive can now accept nearly arbitrary keyword parameters.
For example:
%typemap(in,parse="i",doc="integer") int "...";
%typemap(in,parse="i",doc="integer") int "..."
The purpose of the keyword parameters is to supply code generation
hints to the target language module. The intepretation of the
@ -23949,7 +23951,7 @@ Version 1.3 Alpha 4 (September 4, 2000)
Typemaps can now be specified using string literals like
this:
%typemap(in) int "$target = SvIV($source);";
%typemap(in) int "$target = SvIV($source);"
When code is specified like this, it is *NOT* enclosed
inside a local scope (as with older typemap declarations).