The compiler calls setWindowGrab(bool) instead of setWindowsGrab(NativeWindowType*)
and gives a warning with Visual C++ when calling setWindowGrab(true)
with a pointer to ApplicationContextSDL.
Looks like function function hiding of the non-virtual method.
I can't see this changing testing of the original bug.
When C++ methods are not able to be overloaded in a derived class,
such as when they differ by just const, or the target language
parameters types are identical even when the C++ parameter types
are different, SWIG will ignore one of the overloaded methods with
a warning. A %ignore is required to explicitly ignore one of the
overloaded methods to avoid the warning message. Methods added
in the derived classes due to one of the %interface macros are now
similarly ignored/not added to the derived class.
The adding of additional methods into the parse tree is now more
robust and complete resulting in support for %feature and %rename
for the added methods.
Closes#1277
Language::unrollVirtualMethods was assuming that the using
declaration would only introduce one method. Fix this by adding
in all the overloaded methods from a base class.
Affects code generation in C# and Java, but I was not able
to construct a test that failed before this commit.
Fixes fully qualified names for functions added by using declarations:
- Error messages show fully qualified names in Lua
- Overload warning messages show fully qualified names
- Error messages calling dispatch functions for handling overloaded methods in OCaml, Python and Tcl
Segfault was actually avoided in previous commit ab23cb29.
This commit makes handling more robust in the event of
using %ignore just on the derived method, not tested as it is not
what one should do with directors, and possibly other cases.
Go still segfaults with the new testcase director_using_member_scopes.i.
Issue #1441.
Fix using declaration in derived class incorrectly introducing a method
from a base class when the using declaration is declared before the method
declaration. Problem occurred when within a namespace and the parameter types
in the method signatures were not fully qualified.
Issue #1441
SWIG now handles an interface filename specified on the command line
which contains a closing parenthesis `)`, and more generally with
attributes to `%include` and `%import` which are quoted and contain
parentheses.
Fixes#1006
The regex pattern to upper-case things containing an `i` had incorrect
escaping (`\\(`...`\\)` instead of `(`...`)`) so `import` didn't get
renamed.
This wasn't detected because there were no `_runme` files for this
testcase, so add rename_camel_runme.php which uses reflection to check
the wrapped PHP classes, functions and constants are all named as
expected.
Also expand coverage of converting to underscore case and add coverage
for converting to lower-camel-case.
Related to #1041.
This was introduced by a recent commit adding a testcase matching
an example in the manual. There doesn't seem to be a suitable
termplate in the standard library before C++11, so instead use
a dummy version of std::array defined in the testcase.
Specifying a value on the typemap method now gives an error, e.g.:
%typemap(argout=123) char * ""
The old way of specifying a language name in the typemap attributes
is no longer supported (it has been deprecated for 16 years).
Closes#891
Both function annotations and variable annotations are turned on using the
"python:annotations" feature. Example:
%feature("python:annotations", "c");
struct V {
float val;
};
The generated code contains a variable annotation containing the C float type:
class V(object):
val: "float" = property(_example.V_val_get, _example.V_val_set)
...
Python 3.5 and earlier do not support variable annotations, so variable
annotations can be turned off with a "python:annotations:novar" feature flag.
Example turning on function annotations but not variable annotations globally:
%feature("python:annotations", "c");
%feature("python:annotations:novar");
or via the command line:
-features python:annotations=c,python:annotations:novar
Closes#1951
These functions are added in a number of testcases but for all
languages not just Python. It's tedious having to update the
PHP expected function lists for them, so let's just filter them
out.
Testing is skipped where there is no support for it, that is,
using -builtin or -fastproxy. How to add this support in needs
determining, it's not clear how to do so.
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 log Scilab version at ./configure to ease maintenance. It
uses Scilab include next to the bin directory which will work for both
system-wide install and binaries from scilab.org.
SCILAB_VERSION is define as an automake variable for easier
failure investigation.
Note: the Ubuntu Scilab version is used when available, in the current
CI config there is:
* Scilab 5.5 from scilab.org
* Scilab 6.0 from Ubuntu 18.04
* Scilab 6.1 from Ubuntu 20.04
