Python function annotations containing C/C++ types are no longer
generated when using the -py3 option. Function annotations support
has been moved to a feature to provide finer grained control.
It can be turned on globally by adding:
%feature("python:annotations", "c");
or by using the command line argument:
-features python:annotations=c
The implementation is designed to be expandable to support different
annotations implementations. Future implementations could implement
something like the following for generating pure Python types:
%feature("python:annotations", "python");
or typing module types to conform to PEP-484:
%feature("python:annotations", "typing");
Closes#1561
Issue #735
- Improved documentation for using declarations.
- Issue new warning WARN_LANG_USING_NAME_DIFFERENT when there
is a conflict in the target language name to be used when
introducing a method via a using declaration. Previously
the method was silently ignored. Issue #1840. Issue #655.
An invalid preprocessor expression is reported as a pair of
warnings with the second giving a more detailed message from the
expression evaluator. Previously SWIG prefixed the second message
with "Error:" - that was confusing as it's actually only a warning
by default so we've now dropped this prefix.
Before:
x.i:1: Warning 202: Could not evaluate expression '1.2'
x.i:1: Warning 202: Error: 'Floating point constant in preprocessor expression'
Now:
x.i:1: Warning 202: Could not evaluate expression '1.2'
x.i:1: Warning 202: Floating point constant in preprocessor expression
See #1465
A subexpression in parentheses lost its string/int type flag and
instead used whatever type was left in the stack entry from
previous use. In practice we mostly got away with this because
most preprocessor expressions are integer, but it could have
resulted in a preprocessor expression incorrectly evaluating as
zero. If -Wextra was in use you got a warning:
Warning 202: Error: 'Can't mix strings and integers in expression'
Fixes#1384
This commit handles multi-version support at runtime, it
fixes:
* 5.5.2 - with cutted long identifier name
* 6.0.0 - with full string identifier
* 6.1.0 - with 1 or 0 output argument
It also improves the codebase by:
* Using `Char(X)` instead of `DohCheck(X)` and `Data(X)`
* Using `Len(X)` instead of `strlen()`
* Correctly detecting old Scilab versions
Implementation is very similar to typedef implementation.
Issue #655 and closes#1488.
Testcase using_member.i.
Better implementation to that reverted in previous commit 3f36157b.
Symbol tables shown with -debug-csymbols and -debug-symbols now correct
and are similar to when using a typedef.
If it's not a recognised directive the scanner now emits MODULO and then
rescans what follows, and if the parser then gives a syntax error we
report it as an unknown directive. This means that `a%b` is now allowed
in an expression, and that things like `%std::vector<std::string>` now
give an error rather than being quietly ignored.
Fixes#300Fixes#368
This reverts commit d7e0aaa57d. I can't
get regextarget to work correctly, and the fortran branch no longer
depends on it since pcre support is optional.
The "command" encoder was mostly intended for use in `%rename` - most
uses can be achieved using the "regex" encoder, so we recommend using
that instead.
The "command" encoder suffers from a number of issues - as the
documentation for it admitted, "[it] is extremely slow compared to all
the other [encoders] as it involves spawning a separate process and
using it for many declarations is not recommended" and that it "should
generally be avoided because of performance considerations".
But it's also not portable. The design assumes that `/bin/sh` supports
`<<<` but that's a bash-specific feature so it doesn't work on platforms
where `/bin/sh` is not bash - it fails on Debian, Ubuntu and probably
some other Linux distros, plus most non-Linux platforms. Microsoft
Windows doesn't even have a /bin/sh as standard.
Finally, no escaping of the passed string is done, so it has potential
security issues (though at least with %rename the input is limited to
valid C/C++ symbol names).
Fixes#1806
This is necessary for regex-like renames (where you can't use the #define trick
as is done in many of the %keywordwarn directives). It's now unnecessary to print
the "renaming to '`x`'" code explicitly by the kw.swg files.
We were passing flags of DOH_REPLACE_ANY|DOH_REPLACE_FIRST in three
places, which doesn't make sense as those are mutually exclusive
concepts. In the current implementation DOH_REPLACE_FIRST wins in
this situation, so replace with that and clarify the docs.
The SWIG_PyInstanceMethod_New method is no longer added to wrapped
classes except when it's actually needed, which is when
(!builtin && fastproxy) is true (which it isn't by default).
The SWIG_PyStaticMethod_New method is no longer is now similarly
gated - previously only (fastproxy) was checked.
Finally the C/C++ functions that implement these were always compiled
into the module, but now they're only included if
(!builtin && fastproxy) is true.
Issue noted by vadz in #2190.
When not using -builtin, the self parameter is now still made
available so that user typemaps can use it. Fixes#967.
When using -builtin, fix -Wunused-parameter warnings in the generated
wrapper code. See #801.
Based on a commit peeled out of #801 by teythoon.
Use SWIG_<module>_Init() function to init the module rather than
<module>_Init() as the latter can collide with a function being wrapped.
Fixes#745Fixes#1739
